Česky
Kamil Dudka

Study

File detail

Name:Downloadpdi.txt [Download]
Location: study > min
Size:33.1 KB
Last modification:2009-06-26 20:53

File content

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