wiki.valek.net

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 8. Technologické architektury ======
Cíle technologických architektur. Architektura klient/server, jedno, dvou, třívrstvá a vícevrstvá architektura. Technická a programová realizace. Výhody a nevýhody. Příklady použití.
Analyzujte hlavní problémy integrace technických a softwarových komponent v rámci IS/ICT. Posuďte trendy vývoje v této oblasti.
===== Úloha =====
**Předpoklady:** 
Jste v pozici informatika velkého podniku a je Vám nabízen IS/ICT v architektuře klient/server, respektive s lehkým klientem (NC počítači).

**Zadání:** 
  * Jaké faktory vezmete v úvahu pro hodnocení přijatelnosti daného návrhu pro Váš podnik.

===== Teorie =====
Cílem technologických architektur je propojení a zastřešení architektur SW, HW a datových. Definují formu technického řešení IS/ICT, zda má být vytvořena jako centralizovaná, decentralizovaná, distribuovaná nebo kooperativní, i její podobu – monolitická nebo klient/server (dvouvrstvá, třívrstvá, vícevrstvá). Dále se technologické architektury zabývají formou zpracování dat (dávková, interaktivní, řízená událostmi, v reálném čase) a podobou uživatelského rozhraní.

Podle způsobu zpracování se dělí podle toho – jak dlouho trvá reakce na podnět, zda funguje synchronizovaně s podnikovými procesy a jakými událostmi je startována odezva:

  * dávkové – jednorázově zpracovává dávku dat, v průběhu se do toho nedá sáhnout. Optimální pro složité vědeckotechnické výpočty nebo analýzu rozsáhlých dat, jinak se ale už používá málo a spíše se používá interaktivní zpracování.
  * interaktivní – celkem nejběžnější, rychlá doba odezvy, aplikace reaguje na pokyny uživatele, jedna transakce by neměla trvat déle, než zhruba 1 sekundu
  * řízená událostmi – např. vygenerování objednávky, když zásoba klesne pod limit
  * v reálném čase – technické řízení automatizované výroby

Z hlediska centralizovanosti zpracování dat:

  * centralizované – aplikace běží na jednom počítači, uživatelé se připojují prostřednictvím úplbě blbejch terminálů. Výhoda – jednoduchá spravovatelnost – obsluha má aplikaci plně pod kontrolou, vysoká míra bezpečí; nevýhoda – vysoká zátěž – musí dělat i prezentační logiku, problém s vývojem a změnama, nemůže reagovat na to, co je nového na trhu
  * decentralizované – samostatné počítače, nepropojené – výhody: zátěž je rozložena, když klekne jedno, není celá fabrika v čudu; problém s aktualizací a správou, problém se sdílením dat, nemožné dělat jednotnou datovou základnu, problém s přenosem dat
  * distribuované – část na serveru, část na lokálech – ideální, rozložení zátěže, oddělení jednotlivých vrstev
  * kooperativní – paralelní zpracování úloh

Klient/server – jedno, dvou, třívrstvá architektura
dvouvrstvá – lehký (buď triggery v databázi nebo má aplikace vlastní datovou základnu) a těžký klient

Dvě možnost aplikačního serveru: monitorovací logika – přistupuje v jednom okamžiku jen jeden klient a tvoří se fronta; manažerská logika – je tam manažer jakožto multithreadová aplikace a vytváří se více vláken, z nichž každé obsluhuje v jednom okamžiku jeden požadavek

Způsob komunikace: RPC, messaging, transakční monitor (udržení integrity distribuovaných transakcí)

Technická realizace klient server – standardně DB, aplikační server, klient – IE – v tadytom případě HTML, jinak třeba RPC.
===== Praxe =====

V první řadě bych asi zkoumal, jestli IS poskytuje to co potřebujeme, ale za předpokladu že ano, je třeba vyhodnotit bezpečnost takového řešení, jeho škálovatelnost. Záleží na tom, jestli ty stanice bude možno využít i jinak, pro jiné aplikace, aby se nám na stolech pracovníků nehromadily počítače a naopak jestli se tam dá přistupovat i odjinud nebo jenom od nich. Je třeba vzít v úvahu i kapacity komunikačních linek, atd.

===== Zkouška =====
**2.6.2008** (Novotný, Pecinovský)
  * Při zkoušce chtěli slyšet rozdíl mezi lehkým a těžkým klientem v náročnosti na datové přenosy.