Architektura
Znalostni_Baze_Architektura
Contents
Architektury IS a systémů TPV s ohledem na komunikaci
File/Server
Typická architektura aplikací, ktere jsou určeny pro jednouživatelský provoz (Excel, Access, FoxPro, Clipper, MS Access…). Využitím lokálních sítí Novel, Microsoft
apod. bylo možné sdílet tyto aplikace mezi více uživatelů, ale vzhledem ke své vnitřní architektuře, velmi omezenému (omezené možnosti zamykání dat, určit úroveň
zabezpečení, transakce apod.). Architektura těchto systémů je rozdělena do dvou částí:
▪samotná aplikace, která v sobě zahrnuje prezentační, aplikační a správu datové vrstvy
▪soubory ve kterých jsou uložena data (dbf, xls, mdb apod.)
Aplikace File/Server představuje vzhledem k dnešním požadavkům na komplexnost funkcí balík mnoha souborů, které mají několik desítek až stovek MB. V případě,
že takováto aplikace pracuje v počítačové síti a je instalována na serveru z důvodů centrální správy, představuje i prosté spouštení kritickou zátěž. Dalším problémem
je mechanismus práce s daty, protože tyto aplikace zpracovávají data v podstatě na straně klienta a po jejich zpracování je přesouvají na server (přesouvání velkých
balíků dat a problémy s bezpečností). Z uvedeného vyplývá, že systémy postavené na této architektuře nejsou vhodné pro realizaci aplikací informačních systémů.
Dvouvrstvá architektura Klient/Server
Dvouúrovňová architektura systémů, které většinou
▪vznikly převodem ze systémů využívajích file server architekturu
▪základní architektura starších řešení informačních systémů v prostředí UNIXu, DOSu
Tato architektura většinou neumožňuje provoz v rozsáhlejších sítí (ad 1.), protože kladou příliš velké nároky na kapacitu (šířku) přenosového pásma sítě – data jsou
uložena na databázovém serveru (mnohdy i velmi výkoném), ale samotné zpracování dat probíhá na klientském počítači (porovnejte například výsledek rozpadu
kusovníkového stromu s objemem dat, který je nutný zpracovat). Vhodně naprogramované starší informační systémy jsou sice někdy schopné pracovat i v rozsáhlých sítích,
ale neoplývají příliš velkým uživatelským komfortem a možnosti jejich rozšiřování a úprav jsou velmi omezené. U této architektury platí co bylo uvedeno výše –
i prosté spouštění více klientů této aplikace (tlustý klient obvykle znamená velkou aplikaci) znamená pro síť kritickou zátěž.
Třívrstvá architektura Klient/Server – tenký klient
Třívrstvá architektura klient/server je logickým rozšířením základní dvoúrovňové architektury klient/server. Základní princip je založen na minimalizaci přenosu objemu
dat mezi jednotlivými počítači či aplikacemi. Znamená to, že realizace požadované funkce IS (například rozpad kusovníkového stromu výrobku) je prováděna na počítači
IS (databázový, případné aplikační server) s vysokým výkonem, výsledek této funkce je potom přenesen na klientský počítač – tzn. že klientský počítač plní pouze funkci
prezentační. Samotné zpracování obchodní logiky je řešeno výhradně prostředky serveru aplikace. Toto řešení umožňuje zcela zásadně minimalizovat objem dat
přenášených po síti a umožnit tak i přístup klientům přes nízkokapacitní spoje na server aplikace bez znatelného zpomalení provozované aplikace a současně s minimálním
zatížením používaného přenosového média. Z hlediska informačních systému je uvedené využití třívrstvé architektury klient/server možné u takových aplikací, které využívají
výkonné databázové stroje s bohatými jazykovými možnostmi (Oracle, Microsoft a Sybase) nebo jsou naprogramovány přímo pro aplikační servery (např. Sybase Jaguar
CTS apod.). Aplikace důsledně vytvářené jako třívrstvé se obyčejně vyznačují velice malým klientem řádově jednotky, maximálně desítky MB. U aplikací tohoto typu
je možné poměrně jednoduše zajistit spoušténí jejich modulů ze serveru. Kromě toho jsou tyto aplikace méně náročné na HW vybavení a velikost paměti – například v
případě TPV2000Plus představuje velikost modulu cca. 12 MB proti cca. 150 MB u klasicky vytvořených dvouvrstvývh Klient/Sever aplikací.
Hybridní aplikace (Klient/Server v kombinaci s File/Server)
Vzhledem k tomu, že mnozí tvůrcové aplikací IS mají zásadní problémy s převodem svých starších Klient/Sever nebo File/Server aplikací na novou moderní strukturu,
volí zvláštní metodu – kombinují vícevrstvou Klient/Server a File/Sever architekturu. Znamená to, že jenom část datových struktur převedou na SQL server a další data
zůstavají uložena v nativních formátech FoxPRO, MS Access, Clipper… Tento hybrid může na uživatele budit falešný dojem moderně pojaté aplikace, avšak skutečností
jsou potencionální problémy s bezpečností, zátěží sítě, údržbou datových struktur. Doporučujeme prověřit vnitřní architekturu vašeho IS, protože tato architektura
představuje vysoké riziko z mnoha důvodů (viz výše).
IS využívající WEB rozhranní (MS Internet Explorer, Opera, Netscape)
Nejnovějším trendem při vývoji aplikací je využití internetového prohlížeče ke komunikaci uživatele s informačním systémem. Struktura aplikací, které jsou vyvíjeny
pro tuto platformu plně odpovídá modelu třívrstvé architektury klient/server (např. platforma .NET). Vzhledem k tomu, že ke komunikaci s uživatelem se využívá
internetový prohlížeč, je ovládání takovéto aplikace silně standardizováno a i jeho údržba je snadná a velmi efektivní. Nevýhodou jsou nedostatečné možnosti
pro tvorbu komfortního ovládání, tak aby ho bylo možno využít i pro rutinní práci (což v mnoha případech je právě práce s informačním systémem).
Podpůrné systémy pro aplikace pro komunikaci
CITRIX, MetaFrame, Sybase Web Deployment Kit apod.
Komunikace s využítím produktů CITRIX, MetaFrame, Sybase WDK apod. je založena na využití protokolu ICA (Integrated Console Architecture). Tento protokol
zajišťuje optimalizovanou komunikaci koncového zařízení se serverem. Protokol ICA je založen na přenosu (v některých případech komprimovaném) příkazů grafického
rozhranní (GUI) operačního systému.
Z uvedeného obrázku vyplývá, že k přenosu mezi klientským počítačem a serverem dochází vždy, když dojde ke změně na vstupně/výstupním zařízení (obrazovka,
tiskárna, klávesnice, myš atd.). Přestože se přenášejí pouze příkazy GUI je přenosové médium zatěžováno i v případě, kdy nedochází ke komunikaci se serverem
provozované aplikace (např. prohlížení dokumentu – listování po jednotlivých obrazovkách, pohyby myší apod.). Z pohledu informačních systému a podpůrných
aplikací IS je uvedené řešení výhodné pro zpřístupnění takových aplikací na síti, které ke své činnosti využívají souborově orientované databáze (dBase, FoxPro,
Clipper, MS Access) a především u kterých je předpokládané využití minimální (např. nástroje pro vzdálenou administraci systémů). Mnohé aplikace vytvořené
nativně jako třívrstvá Klient/Server architektura nabízejí optimalizovanější způsoby komunikace při výrazně menší zátěži než řešení pomocí ICA
protokolu.
Architektura systému s ohledem na konfigurovatelnost
Kompaktní aplikace
Protože v aplikaci je uložena jak logika tak i prezentační část, je nutné vždy při jekékoliv změně nebo úpravě překompilovat celý zdrojový program a znova ho
distribuovat uživatelům. Aplikace s takovouto architekturou jsou podstatně méně náročné na svůj vývoj, ale velmi náročné na svojí údržbu a správu. Proto je tento
přístup výhodný pro relativně malé a samostané aplikace, které využívá zanedbatelný počet uživatelů a zároveň není třeba, aby aplikace mezi sebou komunikovali
a to buď přímo nebo s využitím databázového nebo file serveru (Access, FoxPro, Excel apod.). Jeden z problémů kompaktních aplikací je přílišná složitost z hlediska
obsluhy, protože je nabízené množství funkcí, které uživatelů využijí jenom z části.
Vícevrstvé aplikace
Pro systémy které mají neustále odrážet aktuální potřeby uživatelů a mají zároveň mezi sebou spolupracovat je třeba, aby architektura systému umožňovala snadnou
úpravu nebo změnu obchodní logiky, případně prezentační vrstvy. V tomto případě je výhodné oddělit jednotlivé vrstvy systému (prezentační, aplikační a datová vrstva)
a v případě řešení rozsáhlejší problematiky rozdělit ji i z funkčního hlediska do jednotlivých modulů - komponent. Požadavek příslušné změny je potom možné realizovat
za velmi krátkou dobu (využití vzdáleného přístupu, internetu apod) a to pouze se zásahem do příslušné vrstvy systému. Vícevrstvé aplikace v případě využití tenkého
klienta nabízejí většinou uživatelům optimalizovaný soubor funkcí a tím i jednodušší ovládání.
Architektura systému s ohledem na integrovatelnost
On-line a off-line komunikace
Pro volbu režimu přenosu dat mezi systémy je určující jejich potřeba v ostatních systémech a čas za který dochází k jejich změnám. U dat, které se mění zcela
minimálně (například číselník měrných jednotek) je možné data přenášet v dávkovém režimu (off-line přenos). Naproti tomu data, která jsou velmi často aktualizována
je nutné přenášet vždy, když dojde k jejich změně a využívat všech dostupných prostředků pro zachování jejich integrity, především mezi systémy (on-line přenos s
využitím transakčního zpracování dat). Dnešní možnosti tvorby komunikačních rozhraní mohou obsahovat účelnou kombinaci obou režimů. Volba on-line a off-line
režimu závisí tedy na technických možnostech, tak i na množství dat měněných v čase.
Jedna datová základna a komunikace s využitím komunikačního rozhranní
Častým problémem při nasazování různých aplikacích, které mohou využívat společný databázový server je společné využívání databázových entit (tabulek).
Prakticky to znamená, že nad jednou entitou operuje několik aplikací od různých dodavatelů. To je zásadní problém, který prakticky znemožňuje vlastní vývoj a
především případné úpravy a konfigurace jednotlivých aplikací. Jedna datová základna si vynucuje speciální režim při různých formách update a upgrade, protože
vyžaduje i při minimální změně v datových strukturách zásahy do všech aplikací (je to proto i zdroj kritických problémů). Tento problém lze výrazně eliminovat pouze
využitím standardizovaných komunikačních entit a funkcí, které tvoří komunikační rozhraní každé aplikace. Pod společnou správou je potom pouze toto komunikační
rozhranní, což je podstatně méně náročné na údržbu a vzájemnou komunikaci. Tento způsob komunikace umožňuje samostatný vývoj jednotlivých komponent
informačního systému a nevytváří redundantní omezující vazby mezi aplikacemi. Komunikace s využitím komunikačního rozhraní navíc umožňuje volit optimalizovaný
způsob update a upgrade komponent dle skutečných potřeb.
Varianta nonSQL databáze IS a komunikace s řešením TPV:
Varianta databáze typu SQL Oracle, Informix, MS SQL, Progress….:
Architektura systému s ohledem na bezpečnost
Souborové aplikace
Při práci v heterogenním protředí několika aplikací, které spolu potřebují komunikovat je důležité udržet vzájemnou integritu dat v jedntlivých aplikací. U aplikací,
které jsou postaveny na architektuře file serveru (Clipper, FoxPro, dBase, Access apod.) vede víceuživatelský přístup k porušování samotné vnitřní integrity systému
dat (indexové soubory) – v tomto okamžiku je problémové zajistit integritu i vlastních dat. Naprosto je vyloučená i vlastní reakce na tuto událost, která by zajistila
vzájemnou integritu dat mezi aplikacemi. Dalším problémem aplikací, které zpracovávají data na lokálních počítačích a po zpracovaní je přesunou na server, je
problém výpadků napětí, protože i když je serven zajištěn UPS zdrojem napájení, lokální stanice nebývají zajištěny. Proto výpadek lokální stanice má za následek
porušení integrity dat na serveru. Tento problém však nevzniká jenom u výpadků napájení, ale i u jakýchkoliv jiných přerušení činnosti klientského programu
(chyba v programu, datech…).
Transakční aplikace
Informační systémy, které využívají moderní databázové servery jsou schopny reagovat na nesrovnalosti nebo problémy vlastních dat a zajistí tak, aby data v případě
nějaké chyby byly uvedeny do původního stavu. V případě, že komunikaci mezi jednotlivými aplikacemi zajišťuje specializované komunikační rozhraní (které využívá
i vnitřních transakcí databázového serveru) je možné rozšířit působnost transakcí nejenom na více aplikací, ale i na více databázových serverů. Jakákoliv chyba,
která by měla za následek vzájemnou nehomogenitu dat vyvolá příslušný program, který oznámí všem zúčastněným stranám vzniklý problém a uvede data do
původního (homogenního) stavu.
Architektura TPV2000Plus
Architektura TPV2000Plus je postavena na modelu třívrstvé architektury typu klient/server. Klientská část TPV2000Plus tvoří prezentační vrstvu systému s ohledem na
pravidla a zvyklosti v rodině produktů Microsoft Office. Serverovou část systému TPV2000Plus tvoří databázový server Microsoft SQL 7/2000 a aplikační část serveru
je tvořena programy v T-SQL, případně v C, JavaScript apod.
Výhoda toho uspořádání je v tom, že veškeré služby a funkce nad daty TPV zajišťuje aplikační část serveru TPV2000Plus – to umožňuje stejný přístup k datům a
funkcím TPV2000Plus, jak klientským aplikacím TPV2000Plus tak i dalším aplikacím a informačním systémům provozovaných v rámci informační struktury daného řešení.
Toto řešení zcela minimálně zatěžuje síťovou infrastrukturu (naprosto minimální požadavky na šířku přenosového pásma – srovnatelné s provozem www serveru)
a umožňuje velmi jednoduchou administraci celého systému.ˇBezpečnost dat TPV2000Plus je na systémové úrovni zajištěna řízením přístupových práv k SQL serveru
a přístupen do domény Microsoft Windows s možností rozšíření o specializované bezpečnostní systémy s využitím kryptografických metod. Nad systémovou
částí TPV2000Plus je vystavěna politika logických přístupových práv k jednotlivým objektům (rozpiska, postup, atd...) a funkcím (založení položky, rozpisky,
schválení postupu, rozpisky atd...) v TPV2000Plus. Politika logických přístupových práv využívá ke své činnosti dvou klíčů, které se vždy při požadavku realizace
nějaké operace vzájemně porovnávají.
Systém TPV2000Plus je navržen tak, že využívá nejnovějších poznatků ze všech výše uvedených oblastí.
Další odkazy:
Copyright © BB consult engineering s.r.o. 1998-2025.
All Rights Reserved.