Studijní materiály
Detail souboru
Obsah souboru
Copyright (c) 2008 Kamil Dudka.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License".
Prostředí distribuovaných aplikací
==================================
- MiddleWare (http://en.wikipedia.org/wiki/Middleware)
- atomický multi-cast
- potřebuji předat zprávu všem procesům
- buď ji předám všem nebo ji nepředám nikomu
- Lamportovy hodiny - jeden ze základních principů distribuovaných aplikací
Distribuovaný systém
--------------------
- kolekce nezávislých počítačů, která se jeví jejich uživatelům jako
jednoduchý souvislý (koherentní) systém
- požadavky na škálovatelnost (hodně uživatelů, ...)
Distributed computing
---------------------
- decentralizované a paralelní počítání, založené na dvou a více počítačích,
které komunikují přes síť, aby provedli společnou úlohu nebo dosáhli
společného cíle
- existuje mnoho různých typů HW, programovacích jazyků a operačních systémů a
ostatních zdrojů
- výpadek nějakého uzlu (o kterém nic nevíme) by neměl mít vliv na dosažení
cíle - odolnost proti chybám
- příkladem je DNS
- z pohledu HW: stroje jsou autonomní
- z pohledu uživatele: uživatelé si myslí, že pracují s jedním systémem
- komunikace je skrytá před uživatelem
MiddleWare
----------
- skupina procesů, které spolu komunikují a využívají služeb lokálních
operačních systémů
- systém jako celek se chová jako jednoprocesorový se sdíleným časem
Cíle distribuovaných systémů
----------------------------
- sdílení prostředků (ze začátku např. tiskárna (UNIX lpd))
- skrývání komunikace mezi vzdálenými uzly (příkladem je WWW)
- otevřený/škálovatelný (např. programátoři si pak mohou vybrat jaký použijí
programovací jazyk - flexibilita)
- flexibilita taky směrem dolů - DS není monolitický, ale je složený z
komponent - potom jsme schopni některou jeho komponentu nahradit jinou
komponentou
- škálovatelnost (jasné)
Zdroje a uživatelé
------------------
- problém udržení konzistence dat
- kde mají být data uložena (původně tam, kde data vznikala, dnes spíše tam
kde se často používají)
- bezpečnost (šifrování informací, které jdou přes síť, ...)
Transparentnost
---------------
- distribuovaný systém by měl skrývat detaily architektury, komunikace,
reprezentace dat (funkce ntoh, hton, ... na MiddleWare nenajdeme)
- skrývání skutečného umístění dat před uživatelem (data lze přemísťovat bez
vědomí uživatele, pokud padne datové úložiště, najede jiné a uživatel
nemusí nic vědět)
location - umístění dat
migration - změna umístění dat
relocation - lze přesouvat i data, se kterými se právě pracuje
replication - data se klonují na jiné umístění
concurrency - spadne jeden stroj, práci převezme jiný
failure - selhání systému lze skrýt před uživatelem
persistence - uživatel nevidí, jestli jsou data na disku nebo v paměti
Otevřenost
----------
- systém poskytuje služby podle standardizovaných pravidel (standardní syntaxe
/ sémantika), samotná implementace je však skrytá
- otevřenosti se dosahuje používáním rozhraní (interface) - převzato z
objektového programování
IDL = Interface Definition Language (viz. CORBA)
- interoperabilita - dvě implementace spolu mohou koexistovat a pracovat
společně (základy v protokolu TCP - univerzální komunikační prostředek)
- portabilita - aplikace vyvinutá pro distribuovaný systém A může být spuštěna
beze změny na distribuovaném systému B, který implementuje stejný interface
jako systém A
Škálovatelnost
--------------
velikost - snadné přidání uživatelů a zdrojů do systémů
geografická škálovatelnost - těžko dostaneme zpoždění pod 10ms mezi
Evropou a Amerikou :-)
škálovatelná administrace - nezávislá organizace provádí administraci
- techniky škálování
asynchronní komunikace - skrývání pomalé odezvy
replikace, cache - problém s konzistencí (!!)
HW koncepty
-----------
- různé přístupy ke sdílené paměti (multi-procesory, multi-computery)
- bus vs. switch
- propojení přes síť: homogenní/heterogenní
- corssbar - O(n^2)
- omega network (2x2)
- podívat se na obrázky - sl. 16
(https://www.fit.vutbr.cz/study/courses/PDI/private/prednasky/p1.pdf)
- System Area Networks (SANs) - wtf?
SW koncepty
-----------
tightly-coupled - distribuované operační systémy (DOS)
loosely-coupled - síťové operační systémy (NOS)
MiddleWare - transparentní distribuovanost (vrstva navíc)
Operační systémy
----------------
- uni-/multi- procesor
- kernel/user mode
- monolitický kernel / mikrojádro
- IPC, synchronizace (multiprocesorové systémy)
- předávání zpráv (multi-computerové systémy)
- problém se spolehlivým doručováním zpráv
- page-based distributed shared memory
- když není stránka dostupná lokálně, tak se vytvoří kopie
Modely MiddleWare
-----------------
- všechno je soubor (jednoduché)
- distribuované souborové systémy
- RPC
- distribuované objekty
- distribuované dokumenty (WWW)
Služby MiddleWare
-----------------
- komunikace (transparentní přístup)
- pojmenování (entit, které jsou sdíleny)
- persistence (přes distribuovaný FS nebo pomocí DB)
- distribuované operace (atomické operace čtení/zápisu)
- zabezpečení (nejobtížnější služba z hlediska implementace)
- do klasického modelu klient/server byla přidána další vrstva
--> aplikační server
- distribuce: vertikální/horizontální, p2p
- horizontální ... load balancing
Meziprocesorová komunikace v distribuovaných systémech
======================================================
- vrstvené protokoly (TCP/IP)
- protokol T/TCP (TCP for transaction)
- rozšíření TCP protokolu
- rychlejší než TCP
- z pohledu spolehlivosti srovnatelné
RPC = Remote Procedure Call
---------------------------
- pokud komunikujeme na úrovni BSD socketů, není zcela zajištěna
transparentnost komunikace
- RPC je založené na abstrakci volání funkce
- klientovi je skryté, jestli komunikuje přes síť nebo lokálně
- RPC používá volání hodnotou (ale existují i jiné přístupy - call by
reference, call by copy/restore)
- klient na základě volání sestaví zprávu a pošle serveru pomocí lokálního OS
- vzdálený OS předá zprávu serveru, ten ji rozbalí a vykoná proceduru
- potom pošle zpět výsledek volání stejným způsobem
- rozšíření:
LRPC = Lightweight RPC - dveře (doors)
asynchronní RPC
DCE RPC - Distributed Computing Environment
- dynamické distribuované objekty (privátní)
- pojmenované distribuované objekty (sdílené)
RMI = Remote Method Invocation
------------------------------
- volání metod vzdálených objetků
- uvědomit si rozdíl mezi runtime/compilovanými objekty
- používají se wrappery, adaptéry
- statické/dynamické RMI - pokud se u statického RMI změní interface, musíme
překompilovat klienta
- jako parametr můžeme předávat objekt (nepracujeme jen s primitivními typy)
--> lokální objekt se musí překopírovat na server
- podpora v jazyku Java - (téměř) všechny objekty se dají (de)serializovat
- některé objekty nejsou serializovatelné (např. streamy, objekty pracující
s lokálním souborovým systémem)
Komunikace založená na posílání zpráv
-------------------------------------
- třeba posílání mailů :-)
- transient/persistent communication
transient - Berkley sockets, MPI
persistent - message-queuing systems, message oriented middleware
- queue manager, message brokers
Komunikace založená na streamech
--------------------------------
- synchronní, asynchronní
- isochronní (časově omezená z obou stran - např. přehrávání videa)
- algoritmus prosakujícího kyblíku :-)
Distribuované souborové systémy
===============================
SUN Network File System - NFS
-----------------------------
- zajímavá je NFS v4 - vycházelo se také z Windows NTFS
- umožňuje různé síťové technologie na nižších vrstvách
- využívá výhody VFS (nerozlišuje se mezi lokálním a vzdáleným FS)
- NFS v4 podporuje částečné kešování (na straně klienta)
- NFS v3 komunikace je bezstavová (server si nepamatuje, který klient požádal
o která data)
- existuje NFS automounter - samostatný proces, který montuje přípojné body na
žádost
- zabezpečení: podpora ACL
- synchronizace:
a) UNIX sémantika
b) session sémantika - synchronizace se provádí explicitně
- zamykání souborů:
a) shared lock
b) exclusive lock
- Secure NFS - výměna klíčů pomocí Diffie-Hellman
Andrew File System - AFS
------------------------
- transparentní přístup k jednomu ze skupiny file-serverů
- servery organizovány do buněk, které jsou spravovány jako celek
Coda
----
- potomek AFS v2
- založené na RPC2 - spolehlivé volání procedur implementované nad
nespolehlivým přenosem UDP
- využívá RPC2 side effect (např. implementace vlastních protokolů - QoS, RT
transfer)
- MultiRPC - paralelní volání operací, které je transparentní volané straně
(neví jestli přišly požadavky od jednoho nebo více klientů)
- identifikátory:
VID = Volume ID
RVID = Replicated Volume ID
- sezení mají transakční sémantiku
- kešování na straně klienta:
a) callback promisse - server si nechává kopie souborů
b) callback break - server posílá storno zprávy klientům
Remote File Sharing - RFS
-------------------------
- sémantika souborů: UNIX
- stavová komunikace (na straně serveru)
- podpora kešování na straně klienta
- umožňuje mapovat UID/GID ze strany klienta na stranu serveru
DCE/DFS architektura
--------------------
DCE - Distributed Computing Environment (?)
DFS - Distributed File System
Jiné souborové systémy
----------------------
xFS - univerzitní souborový systém (neplést s XFS od SGI)
Plan9
SFS - Secure File System
Clustered File Systems - CFS
----------------------------
- odolnost proti chybám SW/HW
- kolekce spolupracujících serverů
- vyšší škálovatelnost, lepší management
- celá řada prostředí, které používají CFS:
webové farmy
off-host backup - operační systém neví, že je zálohovaný
WebDAV
------
- možnost přístupu/editace souborů pro více uživatelů přes web
- původně navržené pro HTML/XML, ale není omezené na nějaký typ dokumentů
- umožňuje embedded zařízením jednoduše zapisovat na web
- snadno rozšiřitelný protokol
- DASL - DAV Searching and Locating (vyhledávání WebDAV repositories)
- implementováno jako rozšíření protokolu HTTP/1.1
Synchronizace
=============
- fyzické hodiny (krystalový oscilátor, přerušení od tiku časovače, ...)
- víceprocesorový systém: clock skew
- real-time hodiny nebývají příliš přesné (relativní chyba asi 1e-5)
- problém s vlastní definicí času (od roku 1958 máme už asi 30 přechodných
vteřin)
- při synchronizaci času nastává problém se zpožděním komunikace:
Cristian's algorithm
- odhadnu zpoždění odpovědi serveru a odečtu od času, který server pošle
- problém s posunem času zpět (rozbilo by některé algoritmy)
- řeší se zpomalováním času serveru
Berkley algorithm
- aktivní je server
- zjistí průměrný čas na všech stanicích
- čas potom rozešle jednotlivých stanicím
NTP - Network Time Protocol v4
- logické hodiny (Lamport)
- pro distribuované alg. není potřeba znát absolutní čas
- používají se časová razítka
- stačí rozlišit časovou souslednost jednotlivých událostí
- definována relace happens-before
- pokud neplatí x->y ani y->x, události se nazývají konkurentní
- Lamportův alg. přiřazuje časy událostem
- podívat se na sl. 9
- globální stav se skládá z lokálních stavů spolu s událostmi, které jsou
"na cestě"
--> distribuovaný snapshot
Ring Algorithm
--------------
Problém s MUTEXy v distribuovaném prostředí
-------------------------------------------
centralizovaný alg. - přístup řídí koordinátor (lokální fronta)
distribuované alg. - založené na časových razítkách (Lamport)
Token Ring Algorithm
- problém při ztrátě tokenu (uváznutí)
- v základní verzi nepoužitelný
- sl. 25 - shrnutí
Transakce
=========
- SELECT je v SQL read-only transakce
- problém nastává v případě, že se tabulky nevlezou do operační paměti
- ACID transakce:
Atomic
Consistent
Isolated
Durable
- vnořené trasakce - nezávislé podtransakce
(oddělení logické/fyzické databáze)
- distribuované transakce - jedna logická db, více fyzických
- implementace pomocí:
1. private workspace
2. writeahead log
Řízení souběžného přístupu
--------------------------
- kolekce mechanizmů, které zjišťují ACID transakce v distribuovaném systému
- architektura řízení:
1. data manager
2. scheduler
3. transaction manager
- managery je možné propojit do distribuované topologie
- musíme definovat konflikt:
Více transakcí přistupuje k jednomu objektu a alespoň jedna z nich
přistupuje v režimu zápisu.
- transakční logy jsou ekvivalentní, pokud je výsledný stav stejný
- sériový log - všechny akce transakce jsou ukončeny než začnou akce jiné
transakce
- serializovatelný log - lze převést na ekvivalentní sériový log
- dvoufázové zamykání, striktní dvoufázové zamykání
Replikace
=========
- důvody: rychlost, spolehlivost
- modelů replikace je několik (základním rozdílem je, kdo zajišťuje
konzistenci dat - buď middleware nebo aplikace)
- sémantika představuje dohodu mezi procesy a datovým úložištěm
- nejpřísnější sémantika replikace vyžaduje globální hodiny - na základě
časového razítka se zjišťuje, která operace zápisu byla poslední (v reálných
systémech je těžké dosáhnout)
- často se ale používají volnější sémantiky s jednodušší implementací a vyšším
výkonem
Sekvenční konzistence (Lampson)
-------------------------------
- operace jsou prováděny v programovém pořadí, výsledek souběžného běhu není
garantován systémem
- granularita na úrovni čtení/zápisu
Linearizovatelný model
----------------------
- silnější než sekvenční
- transakční zpracování
Příčinná konzistence (causal consistency)
-----------------------------------------
- kauzálně závislé zápisy musí být viděny ze všech procesů ve stejném pořadí
- slabší než předchozí modely
FIFO konzistence
----------------
- slabší než předchozí modely
- v implementaci budeme mít kritickou sekci pro updaty, výsledek kritické
sekce pošleme na všechny repliky (kde se budou updatovat taky v kritické
sekci)
Slabá konzistence
-----------------
- ještě slabší než FIFO
Web proxy
---------
- snižují provoz na sítí
- snižují zatížení serveru
- snižují odezvu u klienta
--> Content Distribution Network (CDN)
- síť proxy serverů na cestě mezi serverem a klientem
- klientovi odpovídá jemu nejbližší proxy server
- důležité je zajistit konzistenci takto poskytovaných dat
(cache consistency)
- pracuje se s expiračním časem dokumentu - pokud je dokument expirovaný, musí
si proxy server vyžádat nový
- dva modely:
1. dotazování serveru
2. leases - server musí být stavový a sám provádět notifikaci o změně dat
- problém, pokud je objekt modifikován často a proxy serverů je
hodně
- silnější konzistence
(objekt může být měněn před datem expirace)
Modely replikace
----------------
1. permanentní replikace (mirror)
2. server-initiated
3. client-initiated
Push-based přístup
------------------
- často přistupované objekty při změně rovnou aktualizujeme
- ostatní objekty pouze invalidujeme a jejich aktualizaci provádíme až o tyto
objekty klient požádá
- server musí být stavový (http protokol je nestavový !!)
Pull-based přistup
------------------
- za udržení konzistence je odpovědná proxy
- proxy se ptá pravidelně serveru, jestli se objekt nezměnil
- na základě serverem zasílaného TTL (nemusí být vždy dodrženo)
Pull-based / intelligent polling
--------------------------------
- proxy určuje obnovovací interval dynamicky za běhu
- pokud se objekt nezmění během dvou dotazů, navýší se dotazovací čas
- pokud se objekt změní mezi dvěma dotazy, sníží se dotazovací čas
- (není potřeba předem znát životnost objektu)
- slabší sémantika konzistence
Hybridní přístup - Leases
-------------------------
lease - doba, po kterou server souhlasí s notifikací proxy
- po vypršení této doby si proxy musí vyžádat nový lease od serveru
Kooperativní caching
--------------------
- viz. CDN (^)
- infrastruktura cache je složena z více proxy
- hierarchický proxy caching (např. squid)
- snaha minimalizovat počet prohledávání (a přistoupit přímo k nejbližší
aktuální kopii dokumentu - např. na základě doménového jména)
Eventuální konzistence
----------------------
- vhodné v případě, že updaty jsou velmi ojedinělé
- příkladem je DNS
Modely konzistence orientované na klienta
-----------------------------------------
1. monotonic read - následující čtení vrací stejnou nebo novější hodnotu
2. monotonic write - zápis musí být proveden na všech replikách před
návratem
3. read your write - proces musí vždy vidět hodnotu, kterou zapsal
4. writes follow reads - čtení bezprostředně po zápisu musí vrátit stejnou
nebo novější hodnotu
Epidemické protokoly
--------------------
- založené na teorii šíření epidemie
- slabě spojené repliky
- založené na pravděpodobnosti...
- šíření epidemie:
a) anti-entropie
b) rumor mongering - "klábosení"
- není garantováno, že všechny repliky update získají
- smazání dat - musíme rozlišit, jestli jsou data opravdu smazaná, nebo jen
nemáme jejich kopii (většinou se řeší tak, že operace delete je chápána jako
update)
Remote-write protokoly
----------------------
- pošlu serveru požadavek na zápis
- čekám na potvrzení zápisu
Local-write protokoly
---------------------
- zapíšu data, informuji server
- nutné držet informaci o tom, kdo je primárním držitelem dat
Quorum-based protokoly
----------------------
- používá se hlasování
- ...
Odolnost proti poruchám
=======================
- poruchu maskujeme tím, že přidáme nějakou redundanci
- na systémech bez redundance znamená systémová chyba katastrofu
- v případě SW lze řešit restartem (na úrovni OS)
- v případě HW je situace mnohem horší
- běžící proces může spadnout (lepší případ)
- v horším případě může vracet nesprávná data
- do nedávna pracovali s počítači technicky zdatní uživatele, kteří vědí, jak
počítač pracuje a vědí, co dělat v případě výpadku
- dnes pracují s počítači "běžní uživatelé", kteří neví, jak počítač pracuje
- je snaha vytvářet spolehlivější počítačové systémy
Základní parametry spolehlivých systémů
---------------------------------------
dostupnost (availability) - jak je systém dostupný v čase
spolehlivost (reliability) - jak dlouho dokáže systém běžet bez chyby
bezpečnost (safety) - chyby nesmí vyvolat katastrofu (jiné požadavky budou
na řízení jaderného reaktoru)
udržovatelnost () - chyby v systému by mělo být snadné opravit
bezpečnost (security) - jak je systém odolný proti útoku
Klasifikace chyb
----------------
transientní - většinou se týkají komunikace (řeší se spolehlivými
komunikačními protokoly)
permanentní - např. chyby paměti (stále na stejných místech)
intermittent - např. špatná operační paměť (chyby na různým místech)
- jiné rozdělení:
crash failure - server spadne, ale do té doby než spadne, tak funguje
správně
omission failure - server nekomunikuje (rozděluje se na receive/send
omission)
timing failure - doba odpovědi serveru překročí stanovený limit
response failure - server odpoví nesprávně
náhodné chyby
Redundance
----------
- řeší se už na nejnižší úrovni (HW)
Výpadek procesu
---------------
- selhání procesů se řeší pomocí seskupování procesů
- několik procesů řeší stejný výpočet
- většina se musí dohodnout na stejném výsledku
- ideální je mít několik nezávislých implementací
(různé architektury, různé jazyky, ...)
- prostředky musí umět definovat na architektuře nezávislé rozhraní
jednotlivých procesů
- snaha vyhnout se identickým chybám
- nevýhodou je nízká efektivita (např. iterpretované vs. kompilované
jazyky)
- skupiny jsou organizované:
a. flat group - problém s dohodnutím se na výsledku
b. hierarchical group - problém s výpadkem koordinátora
- na zkoušce budou výhody/nevýhody těchto architektur:
- systém je K-fault tolerant, jestliže ...
- zpravidla potřebuje k+1 procesů, aby chybu detekoval
Byzantské chyby
---------------
- proces běží, i když nefunguje (generuje chybný, náhodný, nesmyslný výstup)
- "problém byzantských generálů" (podvržené výsledky)
- vzniká potřeba spolehlivého komunikačního kanálu
- otázka je kolik procesů může být chybných vzhledem k celkovému počtu
procesů, abychom chybu dokázali detekovat
--> potřebujeme 2m+1 procesů (Lamport)
Redundance v komunikaci
-----------------------
- spolehlivá komunikace (one to one, one to many)
one to one - např. TCP protokol, RPC, ...
one to many - spolehlivý multicast (ACK based, NACK based)
- existuje několik známých implementací
atomický multicast - zprávu přijmou všechny procesy nebo žádný z nich
- většinou se implementuje na application level
(p2p z pohledu síťové vrstvy)
- distribuovaný commit (dvou- nebo třífázový)
dvoufázový
- fáze volby (kdo provede commit)
- fáze rozhodovací (jestli bude commit proveden, nebo zrušen)
- problém s výpadkem koordinátora (blokování)
--> třífázový commit
třífázový
- stavy: init -> wait -> abort
-> precommit -> commit
- zotavení z chyb (check-pointy, message logging)
Zotavení
--------
- provedení nezbytných operací pro obnovení konzistentního stavu
- obnovený stav nemusí být nutně ten, ve kterém byl systém těsně před výpadkem
- techniky:
nezávislé check-pointy - každý proces provádí nezávisle na ostatních
koordinované check-pointy - drahé z pohledu čerpání systémových prostředků
message logging - TODO
JSP, servlety
=============
(http://www.fit.vutbr.cz/~rychly/pdi/slides-javaee.pdf)
- Java od Sun Microsystems je rozdělena do tří edicí
Java ME
Java SE
Java EE
- snaha osvobodit se od řešení systémových / technických problémů
- komplexní multiplatformní řešení
Aplikační komponenty
--------------------
Čášti aplikace implementované vývojářem aplikace pomocí aplikačních
technologií Java EE.
Aplikační kontejnery
--------------------
Části aplikačního serveru podle specifikace Java EE, které poskytují
prostředí pro běh aplikačních komponent a zprostředkovávají obsluhu jejich
rozhraní s okolním prostředím (spravují systémové zdroje).
JSP = Java Server Pages
-----------------------
- generování dynamických webových stránek
- standardní knihovna: JSTL = Java Server Pages STandard Tag Library
- servlety se používají pro rychlé zpracování HTTP dotazů z webových stránek
- také JSP jsou za běhu aplikace přeloženy do podoby servletů
EJB = Enterprise JavaBeans Technology
-------------------------------------
- používají se pro implementaci aplikační logiky
- základní stavební prvky aplikace
- hierarchické členění aplikace mezi více procesů/vláken
- dva typy:
1. session beans
- zpracovávají data v session
- synchronní komunikace
- stavové / bezstavové
2. message-driven veans
- přidávají asynchronní reakce na události
- přijímají zprávy pomocí Java Message Service (JMS)
JDBC = Java Database Connectivity API
-------------------------------------
- API pro volání SQL dotazů a příkazů
JSF = Java Server Faces
-----------------------
- používá se pro implementaci uživatelských rozhraních webových aplikací
(Java API a XML konfigurace)
- k dispozici jsou různé GUI komponenty
- modely pro různé realizace komponent v HTML a jiných značkovacích jazycích
(standardně HTML/4.01)
- validace vstupních dat, navigace mezi stránkami, ...
JAX-WS = Java API for XML Web Services
--------------------------------------
- mapování XML dat na Java objekty
- pro implementaci poskytovatele i spotřebitele služby
- při volání služby zachovává prostředí a oprávnění dotazu spotřebitele při
zpracování u poskytovatele služby
Java Persistence API
--------------------
- objektově-relační mapování Java objektů
- API pro persistenci objektů, dotazovací jazyk a metadata objektově-relačního
mapování
EAR archiv
----------
- formát archivu je zip
- oproti JAR archivu obsahuje nějaké informace navíc (např. URL webové
aplikace)
Java Servlety
-------------
- podívat se na str. 20/48 (Web Comnponents / JavaBeans Components)
- životní cyklus servletu:
1. vytvoření instance servletu, volání metody init()
2. webový kontejner volá metodu service(), předá jí objekty HTTP
požadavku/odpovědi
3. zpracování dat / generování výsledku
4. odeslání dat klientovi
5. pro odstranění servletu volá webový kontejner metodu destroy()
- je dobré si uvědomit, že tohle všechno běží vícevláknově
--> používají se kritické sekce, monitory, ...
- HTTP servlety mají už konkrétní požadavky/odpovědi (metody POST/GET, ...)
- ve zpracování servletu můžeme předat řízení jinému servletu (který nám jej
potom vrátí - klasické volání metody s předání objektů požadavku/odpovědi)
Ladění servletu
---------------
- servlet běží jako komponenta ve webovém kontejneru
- problém s během ve vícevláknovém prostředí
- doporučuje se test-driven development
- Apache Log4J
JSP stránka vs. Servlet
-----------------------
- podívat se na výhody/nevýhody obou řešení
- JSP stránka může používat tři typy objektů
implicitní objekty - něco jako globální pole v PHP
objekty aplikace - zapouzdřují aplikační logiku
sdílené objekty - poskytují přístup ke sdíleným zdrojům
EJB = Enterprise Java Beans
---------------------------
- serverové komponenty implementované v jazyku Java
- podpora deployment-time konfigurace
- podmínky použití EJB
- třída EJB musí být serializovatelná
- bezparametrický konstruktor (souvisí s předchozím bodem)
- atributy musí být přístupné pomocí get/set
- thread-safe
CORBA
=====
- CORBA = Common Object Request Broker Architecture
- specifikace distribuovaného MiddleWare
- cílem je spolupráce aplikací na různých platformách
ORB = Object Request Broker
---------------------------
- jádro MiddleWare platformy
- zajišťuje komunikaci mezi objekty a klienty
- může být implementován jako knihovna
- objekty a služby jsou specifikovány rozhraním
IDL = Interface Definitino Langugage
CORBA služby
------------
- kolekce - seskupování objektů do seznamů, front, ...
- dotazování - dotazovací jazyk
- řízení souběžného přístupu - podpora zamykání
- události - přerušní na základě nějaké události
Modely volání objektů
---------------------
synchronní - volající je blokován, dokud nepřijde odpověď
one-way - volající pokračuje v provádění (bez čekání na odpověď)
odložený synchronní - volající pokračuje v provádění, ale může blokovaně
čekat na odpověď později
Události a notifikace
---------------------
- existují dva modely:
push-based
pull-based
- používají se oba přístupy
Asynchronní volání metod
------------------------
- podívat se na callback model (sl. 11)
Portable Object Adaptor
-----------------------
- obálka pro kód na straně serveru
(aby vypadal jako objekt navenek)
- umožňuje použití OO jazyků
- podpora jednoho/více servantů (serverů)
- CORBu lze použít k implementaci fault-tolerant systémů
COM (Component Object Model)
============================
- Object Request Broker pro jeden stroj
- DCOM ... Distributed COM
- ActiveX (COM nad Internetem)
- OLE ... Object Linking and Embedding
- COM+
- komponenty používají počítadla referencí (zdroj problémů - na rozdíl
od CORBy)
- virtuální tabulka metod
- COM odděluje rozhraní objektu od jeho implementaci
- rozhraní pomocí IDL, ale není kompatibilní s CORBA
IDL - viz. ^
ODL - Object Description Language
- používá se pro Type Library (repositář typů)
DCOM (Distributed COM)
----------------------
- používá DCE RPC (ne to RPC od MS kvůli problémům big-/little-endian)
- otevřená specifikace (IETF)
Srovnání DCOM vs. CORBA
-----------------------
- objekty mohou implementovat více rozhraní (na rozdíl od CORBy)
- DCOM je striktnější (ve specifikaci standardu)
- DCOM je silně vázán na RPC
Bezpečnost v prostředí distribuovaných aplikací
===============================================
- safety-critical applications
- real-tíme control applications
- dva typy architektur
event-triggered - událost generována zvenčí systému
time-triggered - události se spouští na základě času
X-by-wire
---------
- řízení auta "po drátech" - úplné odstranění mechanických částí na
volantu/brzdách
- používá se v letadlech (v kombinaci s mechanickou zálohou)
- pokud je auto řízeno softwarem, lze přidávat další komponenty:
collision avoidance systems
intelligent highway systems
Nové požadavky na software
--------------------------
- v dnešní době je problémem spolehlivost
- spolehlivost se řeší pomocí distribuovaných systémů
- na druhou stranu je vývoj distribuovaného systému složitější a tím je více
náchylný na chyby
- je snaha co nejvíce zjednodušit (a tím zprůhlednit) vývoj distribuovaných
systémů
- programy musí být certifikované (přišlo z oblasti letectví)
Spring
------
- jedna z distribuovaných architektur
Maft
----
- podobně jako předchozí architektura je dělena do uzlů
- uzly jsou spojeny broadcastovou sběrnicí
- dva oddělené procesory
- umožňuje v případě selhání uzlu v real-time úlohy převést na jiné uzly
- zahrnuje přerušení běhu úloh, které nejsou bezpečnostně kritické
Soft deadline vs. Hard deadline
-------------------------------
- soft deadline umožňuje hodnotu použít, i když se ji nepodaří doručit včas
Linking interface (LIF)
-----------------------
- omezuje funkční a behaviorální popis komponent
- definuje typy dat, komunikační protokol
- definuje syntaxi i sémantiku
Stav systému
------------
- stav systému se může měnit na základě událostí
- rozlišujeme události deterministické (periodické) a neperiodické
- neperiodické události se správně verifikují (kolik alokovat zdrojů
apod.)
- většinou na základě pravděpodobnosti
- rozhraní komponenty nepopisuje celý stav komponenty, ale pouze pohled na něj
Stavová vs. událostní sémantika
-------------------------------
stavová - měříme pouze absolutní hodnotu
událostní - snažíme se zachytit také změny hodnoty (problém ztráty dat)
Detekce byzantských chyb
------------------------
- známé jako konsenzus-problém
- bylo dokázáno, že pro asynchronní systémy je neřešitelné
Integrovaná architektura
------------------------
- kombinace time- a event-triggered
--
(slides 70-78 missing here)
--
Chandy-Lamport Algortihm
------------------------
- proces posílá tzv. marker, uloží si svůj stav jako snapshot
- používá se FIFO
--
(TODO)
--
Phase-king
----------
- počet zpráv roste pouze polynomiálně (na rozdíl od předchozího
exponenciálního)
- každá fáze má dvě kola
- jeden proces je "king" fáze - je schopen ovlivnit volbu
Zpět na hlavní stránku
pdi.txt [Stáhnout]