VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU BAKALÁŘSKÁ PRÁCE 2011 MARTIN MYNARZ

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU

BAKALÁŘSKÁ PRÁCE

2011

MARTIN MYNARZ

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU Nárožní 2600/9a, 158 00 Praha 5

BAKALÁŘSKÁ PRÁCE

PODNIKOVÁ EKONOMIKA

Název BAKALÁŘSKÉ práce

Možnosti systémové integrace ve finančním sektoru Vysoká škola ekonomie a managementu +420 841 133 166 / [email protected] / www.vsem.cz

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU Nárožní 2600/9a, 158 00 Praha 5

TERMÍN UKONČENÍ STUDIA A OBHAJOBA (MĚSÍC/ROK)

10/2011

jméno a příjmení / studijní skupina

Martin Mynarz / PE22

jméno vedoucího BAKALÁŘSKÉ PRÁCE

Ing. Miroslav Vaic

prohlášení studenta Prohlašuji tímto, že jsem zadanou bakalářskou práci na uvedené téma vypracoval samostatně a že jsem ke zpracování této bakalářské práce použil pouze literární prameny v práci uvedené. Datum a místo:

_____________________________ podpis studenta

poděkování Rád bych tímto poděkoval vedoucímu bakalářské práce za metodické vedení a odborné konzultace, které mi poskytl při zpracování mé bakalářské práce. Klepněte

sem a zadejte text.

Vysoká škola ekonomie a managementu +420 841 133 166 / [email protected] / www.vsem.cz

VYSOKÁ ŠKOLA EKONOMIE A MANAGEMENTU

Možnosti systémové integrace ve finančním sektoru System integration options in the financial sector

Autor: Martin Mynarz

Souhrn Obrovská finanční náročnost naprosto univerzálního softwarového produktu (nebo dokonce holá nemožnost jeho vývoje vzhledem ke složitosti problému) spolu s přirozenou chybovostí, znemožňuje vytvoření jediné verze softwarového produktu, který by byl schopen vyhovět všem potenciálním budoucím požadavkům. Proto neustále vzniká nepřeberné množství verzí produktů, jejich mutací, zákaznických modifikací, apod. Různé potřeby se mohou odrazit i v kompletní výměně softwarových technologií. Cílem práce bude přiblížit možnosti systémové integrace ve finančním sektoru. Tak aby z pohledu jednotlivých pod-systémů celek fungoval co nejefektivněji a přinášel společnosti co největší užitek. Summary Huge financial cost absolutely universal software product (or even impossibility of its development due to the complexity of the problem) together with the natural error rate makes it impossible to create a single version of a software product that would be able to meet all potential future requirements. Therefore, there is always a plethora of product releases, their mutations, custom modifications, etc. Different needs can be reflected in the complete exchange of software technology. The aim of the work will bring the possibility of system integration in the financial sector. So that from the perspective of the individual sub-systems unit to operate as efficiently as possible and brought the company reaped. Klíčová slova: SOA, ESB – Enterprise Service Bus, IBM WebSphere MQ, High Availability Keywords: SOA, ESB – Enterprise Service Bus, IBM WebSphere MQ, High Availability JEL Classification: JEL: L630 - Microelectronics; Computers; Communications Equipment

Obsah 1 Úvod.............................................................................................................................13 1.1 „Spaghetti-system“ a jeho nevýhody....................................................................................14

2 Teoreticko část..............................................................................................................17 2.1 Ilustrační příklad..................................................................................................................17 2.2 Nevýhody modelové infrastruktury......................................................................................19

3 Analytická/praktická část ............................................................................................21 3.1 SOA 21 3.2 Enterprise Service Bus.........................................................................................................21 3.2.1 Sběrnice (bus)....................................................................................................................23

3.2.1.1 IBM WebSphere MQ.............................................................................23 3.2.2 Agenti

25

3.2.3 Service repository – repozitář služeb.................................................................................26

3.2.3.1 Orchestrace služeb a orchestrátor..........................................................27 3.3 Backendy..............................................................................................................................29 3.4 Frontendy.............................................................................................................................29 3.5 Rozdílná data a číselníky......................................................................................................29 3.6 Transformace infrastruktury.................................................................................................30 3.6.1 Nový frontend...................................................................................................................31 3.6.2 Nový backend....................................................................................................................32 3.7 Bezpečnost...........................................................................................................................32 3.7.1 Šifrování dat......................................................................................................................32 3.7.2 Digitální podpisy...............................................................................................................34 3.8 Vysoká dostupnost................................................................................................................35 3.8.1 Disaster recovery...............................................................................................................35

3.8.1.1 Režim active/passive.............................................................................35 3.8.1.2 Režim active/active...............................................................................36 3.8.2 Load-balancing..................................................................................................................38

3.8.2.1 Aktivní load-balancing..........................................................................38 3.8.2.2 Pasivní load-balancing...........................................................................39

3.9 Performance throttling..........................................................................................................40 3.10 Správa................................................................................................................................40 3.11 Monitoring..........................................................................................................................41

4 Závěr.............................................................................................................................42 Literatura........................................................................................................................43

Seznam zkratek SOA

Servisně orientovaná architectura

CISC

Customer Information Control System

JCA

JavaTM Cryptography Architecture

RDBMS

Relational DataBase Management System

.NET

Microsoft framework

CRU

Centrální registr úvěrů

MON

Message-Oriented Middlware

HA – High Availability

Vysoká dostupnost systemový prostředků, služeb

LDAP

Lightweight Directory Access Protocol, protokol k řízení přístupu

SSL

Secure Sockets Layer, protokol k zabezpečení komunikace

QoS

rovnoměrné rozložení zátěže dle povahy přenášených dat

DR

disaster recovery – soubor postupů a metod k dasažení business kontinuity

SLA

Service Level Agreement – rozsah a úroveň poskytované služby

Seznam tabulek Tabulka 1 – Překladová tabulka …............................................................................ 18

Seznam grafů [graf 1: investice do vyvoje->navratnost] ............................................................….. 1

Seznam obrázků Obrázek 1 – Aplikace a jejich komunikační moduly ….........................................…... 2 Obrázek 2 – Spaghetti-system ….................................................................................. 3 Obrázek 3 – Modelová infrastruktura …...................................................................... 6 Obrázek 4 – Toky požadavků ...................................................................................…. 7 Obrázek 5 - Princip ESB ….......................................................................................... 10 Obrázek 6 – WMQ jako implementace sběrnice …...................................................... 12 Obrázek 7 – Vnitřní struktura agenta …...................................................................... 13 Obrázek 8 – Agenti a jejich pluginy …......................................................................... 14 Obrázek 9 – Princip orchestrátoru ….......................................................................... 16 Obrázek 10 – Transformovaná infrastruktura …......................................................... 18 Obrázek 11 – implementace sběrnice pomcí WMQ …................................................. 19 Obrázek 12 – Orchestrátor může libovolně nakládat s daty …................................... 23 Obrázek 13 – Data jsou opatřena digitálním podpisem …......................................... 24 Obrázek 14 – Režim active/passive …......................................................................... 25 Obrázek 15 – Režim active/active …........................................................................... 26 Obrázek 16 – Aktivní load-balancing …..................................................................... 27

1 Úvod Jako vše okolo nás, i IT stárne. Stárne hardware i software. Postupem času je hardware stále více stabilní a jeho inovace se projevuje spíše jako zvyšování frekvencí a zvětšování kapacit médií. Software, ač se to možná nezdá, stárne mnohem rychleji – mnohdy je pevně svázán s aktuálními požadavky, na základě kterých je vyvinut. Takové požadavky se mohou velmi rychle změnit během krátkého časového období. To, zda bude softwarový produkt použitelný i poté, závisí do značné míry na velikosti prostředků investovaných do jeho počátečního návrhu. Mnohdy je ale změna požadavků na produkt dramatická a může nastat jedna z následujících situací: 1. produkt řeší požadavky stále z velké části, ale část je nutno uspokojit jinak (nevyplatí se ještě produkt upravovat, protže existuje jiné, rychlejší a levnější řešení) 2. produkt je potřeba upravit (neexistuje rychlé řešení a je to ještě ekonomicky únosné) 3. produkt již není možné nadále použít a je nutná jeho náhrada – kompletní redesign, jeho úplná změna, změna produktu, a podobně Dobře navržené produkty mají zpravidla větší šanci skončit v kategorii 1. nebo 2. Produkty, při jejichž návrhu nebyl kladen velký důraz na rozšiřitelnost či budoucí možný vývoj, skončí pravděpodobně ve 3. kategorii. V některých prostředích může být návratnost objemu investic do návrhu softwarového produktu velmi malá, což může být způsobeno např. příliš častými změnami požadavků kladenými na produkt.

[graf 1: investice do vyvoje->navratnost]

1

1.1 „Spaghetti-system“ a jeho nevýhody Jedno z možných řešení takovýchto situací, které je často využíváno, je dekompozice softwarových produktů na menší funkční celky, které spolu vzájemně komunikují a každý z nich řeší pouze jednu konkrétní úlohu. Limitujícím faktorem ideální formy takovéhoto přístupu (ideální dekompozice) je opět nutnost existence globálního a velmi složitého návrhu, drahá správa, velká složitost infrastruktury a rovněž nutnost každý produkt modifikovat tak, aby mohl komunikovat s okolím. V této fázi již hovoříme o pokročilé softwarové integraci – aplikace jsou upravovány tak, aby poskytovaly rozhraní o byly schopné aktivně komunikovat s jinýmy aplikacemi.

Obr. 1– Aplikace a jejich komunikační moduly (Zdroj: vlastní zdroj autora) Existence velkého množství různorodých aplikací a jejich dodavatelů a znamená velké množství verzí, komunikačních formátů či proprietárních řešení. Postupná softwarová standardizace není prozatím řešením vzhledem k velkému množství standardů použitých různými dodavateli. Komunikace mezi aplikacemi tedy v tomto případě nutně probíhá nehomogenním způsobem – každá aplikace má jiné komunikační rozhraní a neexistuje tedy jednotný způsob komunikace. Takový způsob se neoficiálně a strochou nadsázky označuje jako „spaghetti-system“ – důvod je zřejmý z následujícího obrázku.

14

Obr. 2 – Spaghetti-system (Zdroj: viz použitá literatura) Hlavní a nejvíce viditelná nevýhoda Spaghetti-systemu je naprostý chaos, který musí zdolávat správci systémů. Do určité – velmi malé – velikosti je struktura aplikací relativně dobře spravovatelná bez dodatečných nákladů. Ovšem s přibývajícími aplikacemi složitost komunikační sítě dramaticky roste spolu s náklady na její správu. Mezi zásadní nevýhody tohoto přístupu tedy patří zejména: •

obrovská složitost infrasrtruktury po překročení velmi malého počtu propojených aplikací

•

aplikace nemají jednotné komunikační rozhraní

•

agregace dat z různých aplikací je velmi složitá

•

přenosy dat mezi aplikacemi nejsou škálovatelné

Z výše zmíněného jasně vyplývá, že takto organizovaná infrastruktura je extrémně složitě

spravovatelná a od určitého momentu nerozšiřitelná. Infrastruktura s takto

zásadními negativními vlastnostmi je v dnešní době silně nekonkurenceschopná. Proč ale takto problematická infrastruktura vůbec vzikná? Je jednoznačně výsledkem nekončícího evolučního procesu, kterým prochází každá IT infrastruktura, jejímž limitujícím faktorem je omezená výše investic určených pro její rozvoj. Výše rozpočtu je totiž vždy omezující faktor, který mnohdy určí kvalitu vytvářeného řešení – ta se v budoucnu může negativně projevit a způsobit nemalé problémy. Vývoj IT infrastruktury tedy probíhá pozvolna a iterativně – jen velmi zřídka je možné, pokud mluvíme o

3

středních a větších společnostech typu bank, apod., provádět rozsáhlé změny na úrovni všech systémů. Není na to prostě většinou dostatek financí. Pokud se do této analýzy pustíme ještě hlouběji a zvážíme i fakt, že jakákoliv změna čehokoliv (i malého programu) s sebou nese určité období nestability a vylaďování, zjistíme, že postupná transofmrace může být leckdy výhodnější než plošné a nárazové změny. Pokud se změny dějí postupně a po malých krocích, ovlivní to celkovou stabilitu infrastruktury mnohem méně než kompletní změna/výměna systémů a modelů – zdroje potřebné pro tak velkou akci jsou enromní. Nejedná se teď pouze o finance, ale i na zdroje nutné k řízení transformace a zejména k architektonickému návrhu. Evoluční přístup k této problematice se zdá být mnohem šetrnější a stabilnější. I zde, jako v mnoha odvětvích, je možné hovořit o inspiraci přírodou a jejím evolučním chováním. REF. Novodobým trendem v oblasti softwarové integrace a dalším evolučním krokem IT infrastruktur se proto zdá být SOA – service-oriented architecture. Architektura orientovaná na služby. Výhody, které společnost pomocí SOA získá, jsou z architektonického, finančního pohledu a zároveň z pohledu řízení velmi přínosné. SOA se budeme podrobněji věnovat v následujících kapitolách. Nyní si však celý evoluční proces transformace IT infrastruktury ilustrujme na malém výřezu hypotetické infrastruktury. Budeme postupovat od úplných začátků (separované aplikace bez interakcí) až k SOA jako k evolučně nejvyzrálejšímu řešení.REF.

16

2 Teoreticko část 2.1 Ilustrační příklad Jako ilustrační příklad počátku rozvoje infrastruktury vezměme banku, která pro správu bankovních transakcí používá relativně starý transakční server CICS (Customer Information Control System) běžící na mainframe (dále jen CIC). Tato aplikace neposkytuje žádné rozhraní, pomocí kterého by bylo možné provádět integraci s jinými systémy. Jedinou možností, jak získat data v reálném čase, je analýza obrazovky terminálu – tzv. screen-scraping. Pro analýzu obrazovek je používán tzv. screenscraping engine, což je aplikace, která výsledek analýzy poskytuje formou standardního rozhraní

(v

našem

případě

formou

JCA

konektoru

REF:

http://java.sun.com/j2ee/connector/) klientským aplikacím. Pozn.: I přes své stáří má CICS nesporné výhody, pro které ho ve společnosti plánují používat i nadále: •

díky dlouhodobému používání je maximálně otestován, je stabilní a prakticky bez chyb (nízké náklady na pozáruční podporu a servis), což je u kritické bankovní aplikace naprosto klíčová vlastnost

•

uživatelé ho výborně ovládají (vysoká produktivita práce)

•

přechod na nový program je drahé (koupě licencí, školení, apod.)

Data z obrazovek terminálu jsou dále zpracovávána další aplikací – nové vyvinutou aplikací internetového bankovnictví (dále jen INB) vyvinutou v jazyce Java na platformě JEE. Aplikace je určena pro správu účtů klientů a evidenci kreditních karet. Nově se plánuje zavedení funkčnosti online předschvalování úvěrů. Informace o klientech jsou uloženy v moderním RDBMS Oracle (Oracle je dnes nejpoužívanějším

databázovým

serverem

v

bankovním

prostředí

REF:

http://www.oracle.com/us/products/database/number-one-database-069037.html). Informace v databázi (dále jen ORA) jsou součástí databázové aplikace vyvinuté v jazyce PL/SQL a technologie Oracle Forms.

5

O předschvalování hypotečních úvěrů se stará další aplikace vyvinutá na platformě .NET komunikující pouze pře webové služby (dále jen HYP). I tato aplikace potřebuje, stejně jako aplikace internetového bankovnictví, přímý přístup do databáze klientů. Jako jeden z parametrů algoritmu pro vyhodnocování bonity klientů dále komunikuje s Centrálním registrem úvěrů (dále jen CRU), aby bylo možné ověřit všechny evidované úvěry klienta. Centrální registr úvěrů je tedy další aplikací, která je do infrastruktury zapojena. Jelikož se jedná o externí systém (CRU je využíván většinou bank), je nutné komunikaci zabezpečit firewally Bezpečnostní pravidlo banky navíc znemožňuje přímé propojení interního a externího systému, a proto je nutné zajistit komunikaci přes proxy. Hypotetická infrastruktura obsahuje nyní již dost aplikací pro ilustraci využití pokročilých metod softwarové integrace. Propojení všech plikací CIC, INB, HYP, ORA a CRU vystihuje následující diagram:

Obr. 3 – Modelová infrastruktura (Zdroj: vlastní zdroj autora)

18

Z obrázku je zřejmé, že jsou aplikace již určitým způsobem integrovány – komunikují spolu pomocí modulů jednotlivých aplikací – např. aplikace pro předschvalování úvěrů je v roli konzumenta propojena s ORA a CRU, apod. Proveďeme rychlou analýzu toků požadavků:

Obr. 4 – Toky požadavků (Zdroj: vlastní zdroj autora) Z analýzy plyne, že jsou zde dva typy aplikací – producenti služeb a konzumenti služeb. Mezi producenty patří CIC, ORA, CRU a HYP, konzumentem je opět HYP a INB. Aplikace HYP je tedy zároveň producent i konzument. Producent ORA poskytuje např. službu „změna příjmení zadaného klienta“, apod. Rozdělení aplikací na producenty a konzumenty služeb je důležitým prvkem při návrhu integrační architektury (viz dále).

2.2 Nevýhody modelové infrastruktury Nastíněná modelová infrastruktura má – i když není nijak rozsáhlá – všechny znaky spaghetti-systému. Důvod osvětlí nejlépe příklad: Zavedení nové aplikace (dále APL),která by např. Potřebovala konzumovat služby aplikací INB, HYP a ORA, by pro celou infrastrukturu znamenalo následující změny:

7

1. INB by musela implementovat rozhraní producenta služby zahrnující veškeré komunikační podúlohy (řízení transakcí, bezpečnost, apod.) 2. APL by musela implementovat tři různé způsoby komunikace s producenty ORA, INB a HYP včetně komunikačních podúloh Bod 1. v případě, že se jedná o nový záměr, eliminovat nelze (aplikace INB se producentem stane vždy až po provedení úpravy). Bod 2. však odhaluje problém: vzhledem k nehomogennímu způsobu komunikace je nutné vždy implementovat stále ty samé komunikační úlohy, a to pro každou technologii znovu. Každá nová implementace navíc přináší nestabilní období „dětských nemocí“. Správa komunikačních kanálů je rovněž náročná. Bod 2. tedy vystihuje zásadní problém současného stavu infrastruktury: velmi pracná rozšiřitelnost, tj. nízká flexibilita, tj. nekonkurenceschopnost. Tyto neblahé vlastnosti IT infrastruktury většinou stačí v bance pouze zašeptat a okamžitě se začíná pracovat na analýze možných vylepšení. Takovým vylepšením je právě SOA. Následující kapitoly obsahují stručné definice pojmů SOA, Messaging a ESB – všechny tyto pojmy označují architektonické principy a technologie, které představují vhodné nástroje ke konverzi stávající nevyhovující infrastruktury směrem k mnohem větší flexibilitě, bezpečnosti, spravovatelnosti a stabilitě.

20

3 Analytická/praktická část 3.1 SOA Na poli IT bývá SOA dost často mylně chápána nebo zaměňována za něco, čím není. Stručně řečeno, SOA předepisuje takový způsob integrace, kde jsou využívány služby kontextově naprosto nezávislých aplikací. SOA dále předepisuje způsob, jakým jsou služby popsány a prezentrovány ostatním aplikacím. Velmi častým omylem je spojovat SOA pouze s webovými službami REF!!!. Technologie webových služeb přináší aplikacím možnost vystavit standardní rozhraní pomocí kterého je možné zapojit aplikaci např. do SOA infrastruktury. Čili, technologie webových služeb je pouze jeden z mnoha prostředků, kterým lze implementovat SOA. Samotná možnost volat nějakou aplikaci jako standardní webovou službu nemá nic společného se SOA. SOA tedy není technologie, ale architektura a sada doporučení v jednom. Hlavní vlastností komponent SOA infrastruktury je jejich nezávislost na ostatních a možnost volat jejich služby přes jednotné rozhraní. Tímto rozhraním nemusí být nutně webové služby, ale jakékoliv jiné komunikační technologie - lze např. využít i Messaging (viz dále), běžné síťové i aplikační komunikační protokoly nebo jejich libovolné kombinace. Pokud je SOA jen „doporučením“, jakou technologii lze tedy použít pro integraci? Vyčerpávající odpovědí na tuto otázku je bezpochyby ESB – Enterprise Service Bus.

3.2 Enterprise Service Bus ESB je pojmenování sady produktů, které dohromady poskytují komplexní služby pro sytémovou integraci. Vpomeňme si na situaci připojování nové aplikace do naší modelové

infrastruktury

a

nutnost

opakovaně

implementovat

komunikační,

bezpečnostní a jiné nutné moduly spojené s nehomogenní komunikací. ESB poskytuje komponenty, které tuto úlohu (a mnoho dalších) řeší. Jedná se o tzv. vazební komponenty (binding components), známější spíše po pojmem agenti (tento termín bude dále používán) – viz dále.

9

Dalším – zatím nezmíněným – problémem modelové infrastruktury je negarantovaný přenos dat. Infrastrukturou banky proudí data, jejichž bezpečné doručení je naprosto zásadní úloha. Nečekaná ztráta byť jediného bytu může pro banku znamenat skutečně mnoho problémů. Proto je nutné použít takovou technologii, která umožní garantovat přenos dat mezi aplikacemi (resp. mezi agenty). Takovéto vysokoúrovňové přenosové médium se nazývá sběrnice (bus). Zásadní vlastností sběrnice je garance přenosu dat. V jistém smyslu se přenos dat po sběrnici podobá např. Databázovým transakcím (viz dále). Výše zmíněné komponenty (agenti připojení na sběrnici) umožňují propojení takřka libovolných aplikací, čímž je zajištěn garantovaný přenos dat realizovaný jednotným způsobem. Každá aplikace komunikuje pouze s agentem, který zodpovídá za všechny komunikační úlohy. Jak ale konzument zjistí, kde hledat službu kterou potřebuje, jak se daná služba jmenuje či jaké má názvy a typy parametrů? Všechny tyto informace – definice služeb – jsou uloženy v repozitáři služeb (service repository).

Obr. 5- Princip ESB (Zdroj: vlastní zdroj autora) Základem ESB jsou tedy – kromě poskytovaných služeb – následující technologické komponenty:

22

•

sběrnice (bus)

•

agenti

•

veřejné definice služeb (service definitions)

Podrobně si jejich vlastnosti přiblížíme v následujících kapitolách.

3.2.1 Sběrnice (bus) Hlavní úlohou sběrnice je spolehlivě doručovat informace mezi koncovými agenty, kteří jsou na sběrnici připojení. Sběrnice může být technicky realizovaná mnoha způsoby, ale nejčastěji je jako podkladová technologie použit tzv. messaging. Messaging je obecný název pro technologie, založené na přenostu zpráv. Odtud byl odvozen méně obecný název Message-Oriented Middlware (MOM). Zprávy mohou obsahovat libovolná data a jsou zpravidla zasílány do front, ze kterých si je cílová aplikace aktivně vybírá. Služby, které messaging nabízí jsou velmi vhodné právě pro integrační úlohy, jsou to hlavně: •

velká propustnost při zasílání zpráv

•

garance doručení zprávy

•

transakční zpracování

•

robustní a stabilní platforma

•

podpora machanismů vysoké dostupnosti (HA – High Availability)

•

snadná správa

•

load-balancing

Abychom byli více konkrétní, popíšeme si konkrétní, velmi rozšířený produkt, který představuje vlajkovou loď na poli messagingových systémů – IBM WebSphere MQ. 3.2.1.1 IBM WebSphere MQ Těžiště tohoto produktu (dále budeme používat zkratku WMQ), vhodného zejména pro infrastruktury větších společností, je garantovaný přenos zpráv mezi frontami (fronta = queue). Fronta je objekt, do kterého se přijaté zprávy ukládají, než jsou vyjmuty a zpracovány cílovou aplikací. Fronty nemusí být nutně vybírány systémem FIFO (FirstIn First-Out), ale zprávy je možné vybírat i na základě jiných kritérií. Fronty jsou

11

organizovány správcem front (queue manager), který je spuštěn jakosamostatný proces hostitelského operačního systému. Prozatím abstraktní pojem sběrnice je v případě představení WMQ již o něco uchopitelnější – sběrnice je tvořena množinou propojených queue managerů. Obrázek 6 by pak po zavedení principů WMQ vypadal následovně:

Obr. 6 – WMQ jako implementace sběrnice (Zdroj: vlastní zdroj autora) Jednou z vlastností queue managerů je jejich libovolné propojování a směrování zpráv nezávisle na koncových aplikacích. Zprávy tak lze beze změny aplikací směrovat kamkoliv je potřeba. Sběrnice spolu s agenty tedy umožňuje naprosté oddělení aspektu komunikace od komunikujících aplikací. Flexibilita ESB ale nijak nevynucuje použití právě WMQ. Na trhu existuje řada konkurenčních řešení, z nichž některá jsou nabízena zdarma nebo jako tzv. Open Source (volně šiřitelný zdrojový kód). Mezi zástupce dalších řešení patří např.: •

RabbitMQ REF: http://www.rabbitmq.com/

•

Apache Qpid

•

TIBCO Enterprise Message Service 24

Jako prostředník mezi sběrnicí a aplikací operují zmínění agenti. Jejich obsáhlejší popis zmiňuje následující kapitola.

3.2.2 Agenti Úlohou agentů je poskytnutí jednotného rozhraní pro komunikaci se sběrnicí klientské aplikaci. Není tedy podstatné, jaká aplikace bude druhým koncovým bodem komunikace. To je podstatné vylepšení implementace v porovnání s přímým propojením aplikací v naší modelové infrastruktuře. Producent služby rozhraní používá lehce odlišně než konzument. Všechny aplikace, které figurují v roli konzumenta (tedy aktivně volají službu poskytovanou producenty), použijí stejné rozhraní určené pro přístup ke sběrnici. Jediné, v čem se agenti konzumentů mohou lišit, je platforma, pro kterou jsou vyvinuti (např. Java, C++, C#, apod.). V případě producentů služeb je situace o něco komplikovanější – každý producent může poskytovat data různými způsoby – může se jednat třeba o relační databázi, datový soubor, webovou službu a nebo dokonce i o data z obrazovek terminálu (získávaná pomocí tzv. screen scrapingu). Musí tedy existovat způsob umožňující agentovi připojení k různým typům služeb. Architektonicky velmi zajímavý a efektivní způsob byl implementován např. V integračním frameworku TIF (Trask Integration Framework) vyvinutým společností Trask solutions, a.s REF, který je využíván několika tuzemskými bankami jako páteřní integrační řešení. Agent pro producenty služeb má následující strukturu:

Obr. 7 – Vnitřní struktura agenta(Zdroj: vlastní zdroj autora)

13

Z obrázku je zřejmé, že agent obsahuje tzv. plugin. Jedná se o programovou komponentu, která obsahuje specifický kód zodpovědný za komunikaci se službou. Jedině tato část se pro každý typ služby liší. Pokud je tedy v plánu do infrastruktury připojit službu zcela nového typu, stačí nechat naprogramovat pouze plugin. Zbytek je pak již věcí konfigurace – viz obr.:

Obr. 8 – Agenti a jejich pluginy (Zdroj: vlastní zdroj autora)

3.2.3 Service repository – repozitář služeb V rámci správně implementované ESB musí být každá služba popsána definicí, kterou rozpoznají všichni její konzumenti. Součástí definice je mj. informace o tom, kde se daná služba nachází. Tato informace může mít na různých implementacích ESB různé hodnoty – např. v případě, kdy je použito WMQ jako sběrnice, může být použit název fronty, do které konzument zasílá požadavky, které služba odebírá. Každý konzument může mít definice služeb, které používá, uložené ve svém lokálním repozitáři a nebo je získá z repozitáře globálního – z repozitáře služeb (service repository). Globální repozitář služeb umožní nově připojovaným kontumentům okamžitý přístup ke všem službám infrastruktury. Tento model ovšem není vždy úplně žádoucí z bezpečnostních důvodů – přístup ke globálnímu repozitáři služeb proto mívá zpravidla jen tzv. orchestrátor (viz dále) a ostatní konzumenti služeb čerpají definice ze svých lokálních zdrojů.

26

3.2.3.1 Orchestrace služeb a orchestrátor Služeb ESB se často velmi často využívá v případech integrace kritických aplikací zejména v bankovním sektoru, kde je kladen maximální důraz na spolehlivost přenosů dat. ESB se stává páteřním systémem celé integrační infrastruktury – pomocí agentů a messagingu umožňuje zapojení libovolné aplikace, která tak získá schopnost komunikovat s ostatními zapojenými aplikacemi. V případě rozsáhlé infrastruktury (např. bankovní systémy) je však potřeba komunikaci mezi aplikacemi nějak efektivně řídit - jako příklad vezměme naši pokusnou infrastrukturu a její konzumenty – pouze ti si určují, kdy, odkud a jakým způsobem budou získávat data. Čili logika je zapouzdřena uvnitř konzumentů. Pokud by bylo časem potřeba připojit do infrastrultury jiného konzumenta, musel by tento řešit naprosto stejný problém, tj.: ●

k jakým službám (producentům) se připojit, aby získal požadovaná data

●

jak získaná data transformovat

●

jak s daty naložit (vlastní logika)

Pokud by se celý systém nadále rozrůstal o další aplikace, byla by implementace krajně neefektivní. Navíc v případě, že by nové aplikace načítaly data ze stejné aplikace, bylo by potřeba implementovat výše zmíněné úlohy vícekrát. S využitím ESB zde sice díky agentům odpadá nutnost řešit způsob připojení a některé transformace, vlastní logiku práce s daty je stále nutné programovat. Logikou je zde myšlen proces syntézy dat získaných z více zdrojů. Nebylo by lepší, kdyby klientská aplikace poslala přes ESB požadavek nějaké jiné centrální aplikaci, která by byla zodpovědná za získání všech potřebných dat uložených na jiných systémech, jejich zpracování a konverze? Klientská aplikace by pak dostala pouze požadovaný kompilát - veškerou režii by přenechala centrální aplikaci. Taková aplikace je v dnešní době často využívána – obecně se nazývá orchestrátor.

15

Orchestrátor je integrační komponenta, která, zjednodušeně řečeno, volá služby jiných aplikací (poptává nebo zasílá data, spouští procesy, apod.) a sestavuje z nich kompiláty pro další aplikace. Tento proces se nazývá orchestrace služeb (service orchestration). Samotný orchestrátor poskytuje, stejně jako ostatní producenti služeb, své vlastní služby. Tyto služby jsou většinou abstrahovány jako vyšší implementační vrstva. Jako příklad služby orchestrátoru může být např. získání všech informací o klientovi. Tyto informace ale mohou být roztroušeny po celé infrastruktuře. Úlohou služby orchestrátoru je interně získat data ze všech backendů (voláním jejich služeb, které mu dodají data), jejich následnou kompilací a předáním konzumentovi služby orchestrátoru. Každý požadavek na orchestrátor spouští předem definovaný samostatný proces uložený v jeho databázi. Aby bylo volání orchestračního procesu efektivní, měly by být služby volané procesem pokud možno co nejjednodušší a co nejrychlejší. Schéma zapojení orchestrátoru v infrastruktuře ilustruje následující obrázek:

Obr. 9 – Princip orchestrátoru (Zdroj: vlastní zdroj autora) Jak již bylo zmíněno, orchestrátor vyžaduje přístup ke většině služeb infrastruktury a má přístup ke globálnímu repozitáři služeb, aby mohl získávat jejich definice. Než přistoupíme k transformaci modelové infrastruktury dle doporučení SOA do formy ESB, vysvětlíme si nejprve několik pojmů a mechanismů z bankovního prostředí.

28

3.3 Backendy Bankovní IT infrastruktura sestává typicky s desítek až stovek více či méně izolovaných informačních systémů, které nejsou primárně určeny k prezentaci dat či interních procesů, ale k uchovávání, transformaci nebo různým druhům zpracování rozličných bankovních dat. Souhrnně se jim v bankovním žargonu říká back-office či backendy. V kontextu naší modelové infrastruktury se jedná o producenty služeb. V rámci implementace SOA je snahou připojit k ESB co nejvíce backendů.

3.4 Frontendy Úloha frontendové aplikace nebo-li frontendu je většinou čistě prezentační. Jedná se o globální grafické uživatelské prostředí, které je dost často graficky jednotné jak pro zaměstnance banky, tak i pro klienty. Frontend může být díky SOA velmi univerzální konzumuje služby orchestrátoru a získá tak přesně ta data, která potřebuje. Frontend řeší kromě prezentační úlohy i autentifikaci uživatelů - požaduje po uživatelích identifikaci, která je pak předávána jako speciální bezpečnostní parametr službám, které frontend na základě požadavků uživatele konzumuje. Na základě identifikačních dat je uživateli udělována autorizace pro přístup k systémům a jejich datům. Autorizační data mohou být uložena v jakékoliv formě databáze, často je ale využito výhod adresářových služeb (LDAP, Active Directory, apod.). Jelikož je adresářový server aplikace jako každá jiná, lze i tu pomocí agenta zapojit do SOA infrastruktury a využívat tak jejích služeb jakýmkoliv jiným backendem (např. orchestrátorem pro zjišťění autorizací uživatele, apod.).

3.5 Rozdílná data a číselníky Při integračních úlohách se velmi často stává, že jsou stejná data v různých datových zdrojích reprezentována různě. Příkladem může být informace o pohlaví uživatele. Někdy může být zakódována znaky ‘M’ a ‘Ž’, jinde číselně 0 a 1, apod. Aby bylo

17

možné obousměrně přenášet data mezi různými systémy naprosto transparentně, je nutné použít tzv. číselníkový překlad. Nejedná se o nic jiného než překladovou tabulku, která pro daný typ položky stanovuje její případná konverzní pravidla, a to pro oba směry - do a z aplikace:

Význam

Aplikace A

Aplikace B

Aplikace C

Muž

‘M’

0

‘muz’

Žena

‘Ž’

1

‘zena’

...

...

...

...

Tab. 1 – Překladová tabulka (Zdroj: vlastní zdroj autora)

S pomocí takové tabulky můžeme kdykoliv převést hodnotu zdrojové aplikace na hodnotu požadovanou cílovou aplikací. Zde se např. při načtení hodnoty 1 z aplikace B aplikací C provede konverze 1 -> ‘zena’.

3.6 Transformace infrastruktury Pro transformaci naší modelové infrastruktury směrem k SOA máme již dostatek informací. Následující obrázek zobrazuje transformovaný model – situaci po aplikaci SOA principů.

Obr. 10 – Transformovaná infrastruktura (Zdroj: vlastní zdroj autora)

30

Detailní diagram zachycující případ, kdy je pro implementaci sběrnice použito WMQ:

Obr. 11 – implementace sběrnice pomcí WMQ (Zdroj: vlastní zdroj autora) Transformací infrastruktury dle SOA principů jsme docílili vysoce flexibilního stavu – připojení libovolné aplikace lze provést pouze v několika málo krocích.

3.6.1 Nový frontend Pro připojení nového frontendu (konzumenta) stačí použít vhodného agenta – tj. implementaci agenta pro cílovou platformu (Java, C++, C#, apod.). Většina SOA integračních řešení poskytuje

agenty pro všechny nejrozšířenější platformy. Z

programátorského hlediska ale není závažným problémem vytvořit tzv. cross-platform wrapper (komponenta, umožňující propojení s jinou komponentou na jiné platformě), pokud není vhodný agent k dispozici. Nový frontend tedy použije agenta k připojení ke sběrnici a je ihned schopen konzumovat služby.

19

3.6.2 Nový backend Připojení nového backendu je téměř totožné s připojením frontendu – jediný rozdíl je volba (nebo vývoj) vhodného pluginu, který se postará o transformaci požadavků do a z backendu. Nyní je tedy implementace SOA ve společnosti hotova. Ovšem jen z pohledu uspokojení architektury. Nyní je třeba zajistit dlouhodobou stabilitu a bezpečnost produkčního prostředí zajištěním vysoké dostupnosti a monitoringu kritických (a pokud možno všech) systémů včetně komponent ESB.

3.7 Bezpečnost Bezpečnost je naprosto zásadní vlastnost každé infrastruktury – čím je komplexnější, tím je více zranitelná a napadnutelná. Cílem zabezpečení infrastruktury je doručení dat od producenta ke konzumentovi, aniž by byla data „odposlechnuta“ (eavesdropping) nebo modifikována třetím – neoprávněným – subjektem. Obecně existuje několik základních typů útoků, před nimiž je nutné infrastrukturu ochránit: •

neoprávněný přístup k datům (odposlech)

•

neoprávněná modifikace dat

•

impersonifikace – útočník zfalšuje identitu, jejíž oprávnění zneužívá

Hrozbu obou typů útoků lze eliminovat s použitím moderních kryptografických metod implementovaných dnes na všech platformách – jedná se o šifrování přenášených dat a digitální podpisy.

3.7.1 Šifrování dat Jako nástroj pro šifrování přenášených dat mezi komunikujícími systémy dnes téměř výhradně slouží protokol SSL (Secure Sockets Layer). Protokolem SSL je dnes možné zabezpečit všechny nejpoužívanější komunikační protokoly, jakými jsou např. TCP/IP, HTTP nebo LU 6.2 (používá se pro komunikaci s Mainframe systémy či systémy IBM i). Pomocí SSL lze vytvořit šifrovaný kanál, který je extrémně těžké odposlouchávat. 32

Velká bezpečnost SSL je postavena výhradně na důvěře. Toto zjištění se může zdát šokující, ale je tomu skutečně tak. Důvěrou je zde myšlena důvěra v autenticitu certifikátů minimálně jedné ze stran. Aby bylo možné SSL kanál otevřít, musí se mininálně jedna (což je určeno konfigurací kanálu) z komunikujících stran prokázat digitálním certifikátem, který je vydán důvěryhodnou certifikační autoritou. Sama certifikační autorita se rovněž prokazuje certifikátem. Komunikující systémy si vymění certifikáty a zkontrolují, zda jsou pro ně důvěryhodné (každá ze stran spravuje svůj vlastní seznam důvěryhodných certifikátů). Tímto způsobem je zajištěna autenticita komunikujících stran, které si (zjednodušeně řečeno) následně vymění symetrický klíč, kterým se bude šifrovat celá další komunikace. Podrobný proces SSL handshake, jak se navazování SSL komunikace nazývá, je následující: 1. Klient pošle serveru požadavek na SSL spojení, spolu s různými doplňujícími informacemi (verze SSL, nastavení šifrování atd.) 2. Server pošle klientovi odpověď na jeho požadavek, která obsahuje stejný typ informací a hlavně certifikát serveru 3. Podle přijatého certifikátu si klient ověří autentičnost serveru. Certifikát také obsahuje veřejný klíč serveru 4. Na základě dosud obdržených informací vygeneruje klient základ šifrovacího klíče, kterým se bude šifrovat následná komunikace. Ten zašifruje veřejným klíčem serveru a vrátí ho zpět 5. Server použije svůj soukromý klíč k rozšifrování základu šifrovacího klíče. Z tohoto základu vygenerují jak server, tak klient hlavní šifrovací klíč 6. Klient a server si navzájem potvrdí, že od teď bude jejich komunikace šifrovaná tímto klíčem. Fáze handshake tímto končí 7. Je ustaveno zabezpečené spojení šifrované vygenerovaným šifrovacím klíčem 8. Aplikace od teď dál komunikují přes šifrované spojení Z postupu je zřejmé, že existují dva typy klíčů – soukromý (private key) a veřejný (public key). Oba jsou základem tzv. asymetrického šifrování. Zjednodušeně řečeno,

21

data, která jsou zašifrována veřejným klíčem mohou být dešifrována pouze klíčem soukromým.

3.7.2 Digitální podpisy Zabezpečení komunikačního kanálu pomocí SSL zaručí, že nebude možné odposlechnout data přenášená mezi dvěma systémy. Existuje řada scénářů, kdy není komunikace takto přímočará – vzpomeňmě si např. na orchestrátor a aplikace, které jeho prostřednictvím komunikují s ostatními aplikacemi. Situace tedy může vypadat následovně:

Obr. 12 – Orchestrátor může libovolně nakládat s daty (Zdroj: vlastní zdroj autora) Z obrázku je patrné, že orchestrátor přijme data od aplikace A sice po zabezpečeném kanálu, ale sám je má k dispozici v nešifrované formě. Pokud případný útočník napadne orchestrátor, může data libovolně změnit a zaslat již změněná aplikaci B (zabezpečený kanál už teď ničemu nepomůže – zabezpečí přenos již kompromitovaných dat). Řešením je data digitálně podepsat ještě před odesláním orchestrátoru a podpis zkontrolovat po přijetí aplikací B. Podepisovací algoritmus vytvoří z podepisovaných dat a s využitím soukromého klíče digitální podpis (digital signature), který bude ověřen až po přijetí aplikací B (ta musí vlastnit stejný soukromý klíč jako aplikace A). I když by se útočník pokusil po cestě změnit data, aplikace B to po vypočtení digitálního podpisu přijaté zprávy zjistí (podpisy nebudou stejné). Pokud útočník změní data a zároveň k nim vypočte i digitální podpis, verifikace aplikací B opět selže neboť útočník nepodepsal data stejným privátním klíčem.

34

Obr. 13 – Data jsou opatřena digitálním podpisem (Zdroj: vlastní zdroj autora)

3.8 Vysoká dostupnost V produkčním prostředí jsou na bankovní IT infrastrukturu kladeny velmi vysoké požadavky na kvalitu dostupnosti služeb (Quality of Service – QoS). U kriticky důležitých systémů je proto nutné předcházet výpadkům jak hardware tak i software (např. systémových zdrojů, apod.). Existuje řada způsobů, jak vysokou dostupnost systémů - tzv. High Availability (HA) – zajistit a tím minimalizovat dobu, kdy jsou služby systémů nedostupné nebo nefunkční. Obecně se vždy jedná o nějakou formu tzv. disaster recovery (DR) řešení.

3.8.1 Disaster recovery Implementace DR řešení spočívá ve vytvoření identických stínových instancí (počet není omezen) aplikace u které je potřeba dosáhnout maximální možné dostupnosti. Vzhledem k velkému množství faktorů, které mohou chod aplikace negativně ovlivnit, není možné každý monitorovat či předvídat všechny negativí scénáře. Proto jsou k dispozici zmíněné stínové instance, které jsou v případě výpadku uvedeny do provozu v co možná nejkratší době. Dle dostupných prostředků (omezený počet licencí, omezený počet serverů, apod.) a/nebo dle nastavení SLA (service level agreement – smluvně stanovená maximální doba výpadku) se DR řešení provozuje ve dvou režimech: active/passive a active/active. 3.8.1.1 Režim active/passive V tomto režimu spustí proces přepínání na stínovou instanci výpadek hlavní instance aplikace, který je detekován v rámci aplikačního monitoringu (viz kap. Monitoring). Jakmile je proces přepínání spuštěn, aplikace je nedostupná – chybující instance se úplně odstíjní od infrastruktury, zatímco se do provozu zavádí její náhrada. Celý proces může trvat až několik minut v závislosti na implementaci DR řešení.

23

Obr. 14 – Režim active/passive (Zdroj: vlastní zdroj autora) 3.8.1.2 Režim active/active Tento DR režim je použit v případě, že je nutné minimalizovat dobu výpadku na co možná nejkratší dobu a v ideálním případě přepnout na záložní instanci již při prvním výskytu určitého typu chyb hlavní instance. Toho se dá docílit jedině tak, že jsou záložní instance v provozu a jsou připraveny okamžitě převzít zpracování. Režim active/active může být provozován ve dvou formách: •

stínové instance jsou spuštěny, ale neúčastní se provozu

•

stínové instance jsou spuštěny, a účastní se provozu

V prvním případě je po výpadku hlavní instance se okamžitě přepíná na záložní instance a provoz pokračuje. I zde je nutné počítat s režií nutnou na přepnutí (izolace chybující instance a přepnutí na náhradníka).

36

Obr. 15 – Režim active/active (Zdroj: vlastní zdroj autora) Je nutno podotknout, že je nutné monitorovat nejen instance aplikací, tak i stav jejich agentů. Vysoká a maximálně bezvýpadková dostupnost je zachována pouze v případě pádu agenta. Ten přestane kvůli chybě odebírat požadavky ze sběrnice, což je ideální stav. Pokud nastane chyba aplikace, musí být okamžitě odstaven její agent, aby nedošlo ke konzumaci požadavků, které ale vlivem chybující aplikace nebudou zpracovány. Případ, kdy se stínové instance přímo účastní provozu, zaručuje prakticky nepřerušenou dostupnost. Cenou za rychlost jsou ovšem vyšší náklady na licence a hardware, který je nutné mít k dispozici navíc oproti režinu active/passive. Nejvyšší bezpečnosti je dosaženo po geografickém oddělení záložních instancí.

25

3.8.2 Load-balancing Aby se mohly všechny instance kritické aplikace dělit o provozní úlohy, musí existovat způsob jejich přidělování, což znamená i rozdělení zátěže mezi instance (loadbalancing). O to se může starat buď speciální komponenta, která aktivně posílá požadavky dle předem stanoveného schématu (aplikace je tedy z pohledu této komponenty pasivní) a nebo si požadavky vyzvedává aplikace sama (je tedy aktivní).

3.8.2.1 Aktivní load-balancing Metodu aktivního load-balancingu si vysvětlíme na příkladu dvou instancí aplikace APL – APL1 a APL2. Obě instance běží vůči sobě v režimu active/active (není je tedy potřeba rozlišovat hlavní a záložní) a jsou pomocí agentů připojeny na sběrnici implementovanou pomocí WMQ. Oba agenti, A1 a A2 jsou připojeni na sdílenou MQ frontu, ze které aktivně získávají zprávy (=požadavky). Jelikož jsou servery hostující instance APL1 i APL2 identické (např. identické virtuální stroje), dá se očekávat rovnoměrné rozložení zátěže (oba agenti budou konzumovat přibližně stejné množství zpráv). Rozdělování zátěže si ale obě instance řídí samy. Pokud se jedna z instancí porouchá, přestane odebírat zprávy – ty ale bude stále odebírat druhá instance, čímž automaticky dostojí nárokům na active/active režim.

Obr. 16 – Aktivní load-balancing (Zdroj: vlastní zdroj autora) 38

3.8.2.2 Pasivní load-balancing Na rozdíl od aktivniho load-balancingu se pasivní load-balancing liší právě přístupem aplikací k přidělovaným úlohám. Resp. přidělování úloh se děje obráceně – je řízeno jinou komponentou. Příklad pasivního load-balancingu si ilustrujme na příkladu dvou HTTP serverů, mezi které rozděluje zátěž tzv. edge komponenta nebo. Edge komponenta je nízkoúrovňová aplikace, která přijímá požadavky na zadaném DNS aliasu a pro každý požadavek provede bleskovou kalkulaci cílového serveru. Dle výsledku změní DNS záznam aliasu tak, aby obsahoval IP adresu cílového serveru a dotaz mu přepošle.

Obr. 17 – Pasivní load-balancing (Zdroj: vlastní zdroj autora) Pokud jsou servery výkonově rovnocenné, používají se při výpočtu většinou váhy 50:50. V případě různých výkonů serverů lze nastavit váhy tak, aby nebyl méně výkonný server přetěžován. Pasivní load-balancing umožňuje rozdělovat zátěž dle přesných kritérií a lze tak při výpočtu využít např. i zpětnou vazbu v podobě informací o aktuálním vytížení serverů, apod. Aktivní load-balancing na druhou stranu vytěžuje aplikace přesně dle potřeby.

27

3.9 Performance throttling Aby bylo možné zajistit konstantní dobu odezev, měřitelnost služby a ušetřit výkon serverů (má smysl pouze při využití virtualizace), využívá se mechanismus nazvaný performance throttling, doslova škrcení výkonu (jedná se o analogii používanou moderními procesory pro snížení spotřeby energie). V praxi to znamená umělé snížení výkonu všech instancí tak, aby se součet všech jejich snížených výkonů rovnal plnému výkonu jediné instance. Tři identické instance jedné aplikace by tak měly využívat pouze 33.3% výkonu svých hostujících serverů. V případě výpadku jedné z instancí se výkon zbývajících dvou dynamicky zvýší na 50%. Jediná instance pak využije 100%

výkonu. Výkon služby jako celku je ale stále

konstantní a v příadě, že jsou servery instancí virtualizovány, výkon může být využit jiným serverem ve virtuální farmě.

3.10 Správa I přes rozsáhlost infrastruktury včetně všech HA a DR řešení je nezbytně nutné zajistit její bezchybný chod. I když se může zdát, že automatické systémy a aplikace nepotřebují pro svůj provoz žádný personál, není tomu tak. Složitost celé infrastruktury je tak vysoká, že nelze dokonale pokrýt všechny chybové stavy, které mohou nastat – tedy např.: ●

přetečení kvóty na diskovém poli způsobené nadměrným logováním

●

nedostatek operační paměti způsobený chybou aplikace

●

přetížení serveru z důvodu extrémního počtu požadavků

●

vypršení platnosti aplikačního certifikátu

●

aplikační chyba, která nebyla odhalena při testech

●

chyba hardware

●

a mnoho, mnoho dalších

Kvalifikovaná obsluha musí chybový stav co nejrychleji opravit a systém uvést do původního stavu nebo navrhnout dočasné krizové řešení do doby, než bude problém opraven. Klíčem k rychlé opravě je však bleskový monitoring všech systémů. 40

3.11 Monitoring Každá aplikace zapojená do produkční bankovní infrastruktury musí být patřičně monitorována, aby bylo možné ihned reagovat na případné chyby, které při jejím běhu mohou nastat. Kromě monitoringu jednotlivých aplikací je nutné monitorovat také např.: ●

stav transportní vrstvy (messaging)

●

zátěž CPU na serverech

●

velikost volné operační paměti serverů

●

volné místo na discích či diskových polích

●

počet zpracovávaných požadavků konkrétní aplikací

●

doby odezev on-line systémů

●

apod.

Na trhu existuje velké množství kvalitních monitorovacích systémů, ale není bohužel možné použít jeden monitorovací systém na celou infrastrukturu. Je totiž tak různorodá, že by se vývoj jednotného systému pravděpodobně nevyplatil a nebo by byl extrémně drahý. Nicméně, i mezi monitorovacími systémy existují zavedené standardy, díky nimž je lze integrovat a poskytnout technické podpoře jednotné informace v pravou chvíli.

29

4 Závěr TBD

42

Literatura Primární zdroje Libor Gála, Jan Pour, Zuzana Šedivá Podniková informatika, 2 přepracované a aktualizované vydání, Praha : Grada, 2009. 496s. ISBN 978-80-247-2615-1 Erl Thomas SOA servisně orientovaná architektura, kompletní průvodce, Brno : Computer Press, 2009, 671 s. ISBN 978-80-251-1886-3 Kareem Yusuf Enterprise messaging using JMS and IBM WebSphere, Prentice Hall PTR, 2004. 330 s. ISBN 0-13-146863-4

Monografie Jan Pour Informační systémy a technologie, VŠEM 2006. 492 s. ISBN 80-86730-03-4

On-line publikace Jan van Bon ITIL V3 – A Pocket Guide, Van Haren Publishing, ISBN 978 90 8753 1027 -http://books.google.com/books? id=E0xJeX3FwzgC&printsec=frontcover&dq=itil+v3&hl=en&ei=MwpLTYmfBJG1hA fCwOGNDw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CD0Q6AEwAA#v =onepage&q&f=true Internetové zdroje Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, WWW:http://www.w3.org/TR/wsdl Demystifying SOA - Myths About SOA Web Services Architecture, Published September 22, 2005, Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved. WWW: http://soa.sys-con.com/node/121947

31

Zdroj obr.2 - http://www.google.cz/imgres?q=Spaghettisystem&hl=cs&sa=X&biw=1280&bih=914&tbm=isch&tbnid=tU_iAOqnk8rqM:&imgrefurl=http://makingsoawork.blogspot.com/2010/08/integrationspaghetti.html&docid=Yf37cIX1hXubAM&w=409&h=228&ei=jx4zTvqOHsLMhAez wfyVCw&zoom=1&iact=rc&dur=731&page=2&tbnh=103&tbnw=184&start=28&ndsp =30&ved=1t:429,r:25,s:28&tx=99&ty=53

44