Distribuovaný AIS se stal každodenní realitou. Mnoho podnikových AIS používá distribuované databáze. Byly vypracovány metody distribuce dat a správa distribuovaných dat, architektonické přístupy zajišťující škálovatelnost systémů, implementace principů vícevrstvé architektury klient-server i architektura střední vrstvy.

V praxi se začínají uplatňovat mobilní architektury. To platí jak pro databázové systémy, tak pro webové aplikace.

Oživuje se přístup k budování distribuovaných systémů založených na architektuře peer-to-peer, ve kterém na rozdíl od architektury klient-server, která dnes v distribuovaných systémech dominuje, nejsou role interagujících stran v síti pevně dané. Přidělují se v závislosti na situaci v síti, na vytížení jejích uzlů.

V souvislosti s intenzivním rozvojem komunikačních technologií se mobilní AIS aktivně rozvíjí. Byly vyvinuty technické prostředky a software pro jejich tvorbu. To vedlo k vývoji mobilních databázových systémů. Mnoho výzkumných týmů provádí výzkum specifických vlastností takových systémů a vytváří jejich různé prototypy. Technologie Java se staly důležitým nástrojem pro vývoj mobilního softwaru.

Byl vytvořen standard WAP (Wireless Application Protocol), který již podporují některé modely mobilních telefonů. Na základě WAP a XML vyvinulo W3C značkovací jazyk pro bezdrátovou komunikaci, WML (Wireless Markup Language).

Při vývoji AIS se začala věnovat větší pozornost metadatům. Zde se postupuje ve dvou směrech – standardizace prezentace metadat a zajištění jejich podpory v systému.

AIS využívá různé způsoby a prostředky prezentace metadat (různé druhy úložišť metadat). Nedostatečná unifikace v této oblasti výrazně komplikuje řešení problémů aplikační mobility, opětovného použití a integrace informačních zdrojů a informačních technologií a také reengineeringu AIS.

K překonání těchto potíží se aktivně usiluje o vývoj standardů metadat zaměřených na různé informační technologie. V této oblasti již existuje řada mezinárodních, národních a oborových standardů, které definují prezentaci metadat a výměnu metadat v AIS. Některé z nich již získaly status de facto standardů. Zde se omezíme na zmínku pouze těch nejvýznamnějších z nich.

Pravděpodobně prvním de facto standardem pro tuto kategorii byl jazyk pro popis dat CODASYL pro síťové databáze. Je třeba jmenovat následující standardy: standard dotazovacího jazyka SQL pro relační databáze obsahující definici tzv. informačního schématu - souboru reprezentací schémat relačních databází; standardní komponenta databáze objektů ODMG, která popisuje rozhraní úložiště schémat objektů; mezinárodní standard IRDS (Information Resource Dictionary Systems), který popisuje systémy pro vytváření a údržbu adresářů informačních zdrojů organizace.

Dále je třeba zmínit standard Common Warehouse Metamodel (CWM) pro reprezentaci metadat datového skladu vyvinutý konsorciem OMG, založený na dříve vytvořeném standardu OIM (Open Information Model) konsorciem MDC (Meta Data Coalition) pro širší účely. .

Nová platforma technologie XML pro web také zahrnuje standardy prezentace metadat. Podpora metadat je jednou z nejdůležitějších inovací webu, která radikálně mění technologii správy jeho informačních zdrojů. Zatímco podpora metadat byla původně vyžadována v databázových technologiích, metadata nebyla podporována na webu první generace.

Standardy webových metadat zahrnují podmnožinu jazyka XML používaného k popisu logické struktury určitého typu dokumentu XML. Tento popis se nazývá DTD (Document Type Definition). Platforma XML navíc zahrnuje standard XML Schema, který nabízí pokročilejší možnosti pro popis dokumentů XML. Standard Resource Definition Framework (RDF) definuje jednoduchý jazyk reprezentace znalostí pro popis obsahu dokumentů XML. A konečně, nově vznikající standard OWL (Ontology Web Language) definuje formální jazyk popisu ontologie pro sémantický web.

Standard Unified Modeling Language (UML), který poskytuje reprezentaci metadat pro CASE vizuální analýzu objektů a návrhářské nástroje, byl vyvinut konsorciem OMG. Tento jazyk je podporován v mnoha softwarových produktech CASE. OMG také vytvořila standard XML Metadata Interchange (XMI) pro výměnu metadat mezi CASE nástroji pomocí UML.

Zde je třeba zmínit také standard Dublin Core (DC), soubor prvků metadat pro popis obsahu dokumentů různé povahy. Tento standard si rychle získal oblibu a našel široké použití zejména ve webovém prostředí (viz část 3.3).

Pokračují práce na vývoji stávajících a vytváření nových standardů pro prezentaci metadat pro AIS. Podrobnější informace o předmětných normách naleznete v encyklopedii.

Podle známého odborníka v oboru informatiky E. Tanenbauma neexistuje obecně uznávaná a zároveň striktní definice distribuovaného systému. Někteří rozumní argumentují, že distribuovaný je takový výpočetní systém, při níž nefunkčnost počítače, o jejíž existenci uživatelé dříve ani netušili, vede k ukončení veškeré jejich práce. Značná část distribuovaných počítačových systémů tuto definici bohužel splňuje, ale formálně se vztahuje pouze na systémy s jedinečným bodem zranitelnosti ( jediný bod selhání).

Při definování distribuovaného systému je často kladen důraz na rozdělení jeho funkcí mezi několik počítačů. S tímto přístupem je distribuován jakýkoli výpočetní systém kde je zpracování dat rozděleno mezi dva nebo více počítačů. Poněkud úžeji distribuovaný systém lze na základě definice E. Tanenbauma definovat jako soubor nezávislých počítačů propojených komunikačními kanály, které z pohledu uživatele nějakého softwaru vypadají jako jeden celek.

Tento přístup k definování distribuovaného systému má své nevýhody. Například vše, co se v takovém distribuovaném systému používá software by mohl fungovat na jednom počítači, ale z pohledu výše uvedené definice již takový systém distribuován nebude. Koncepce distribuovaného systému by proto měla být pravděpodobně založena na analýze softwaru, který takový systém tvoří.

Jako základ pro popis interakce dvou entit zvažte obecný model interakce klient-server, ve kterém jedna ze stran (klient) iniciuje výměnu dat odesláním požadavku druhé straně (serveru). Server požadavek zpracuje a v případě potřeby odešle klientovi odpověď (obr. 1.1).

Rýže. 1.1.

Interakce v rámci modelu klient-server může být buď synchronní, kdy klient čeká, až server zpracuje svůj požadavek, nebo asynchronní, kdy klient odešle požadavek na server a pokračuje v jeho provádění, aniž by čekal na server. Odezva. Model klienta a serveru lze použít jako základ pro popis různých interakcí. Pro tento kurz je důležitá interakce jednotlivých částí softwaru, který tvoří distribuovaný systém.

Rýže. 1.2.

Uvažujme určitou typickou aplikaci, kterou lze v souladu s moderními koncepcemi rozdělit do následujících logických úrovní (obr. 1.2): uživatelské rozhraní(PI), aplikační logika (LP) a přístup k datům (DD), práce s databází (DB). Uživatel systému s ním komunikuje prostřednictvím uživatelského rozhraní, databáze ukládá data popisující doménu aplikace a vrstva logiky aplikace implementuje všechny algoritmy související s předmětová oblast.

Protože v praxi mají různí uživatelé systému obvykle zájem o přístup ke stejným datům, bude nejjednodušším oddělením funkcí takového systému mezi více počítači oddělení logických vrstev aplikace mezi jednu serverovou část aplikace. , který je zodpovědný za přístup k datům, a klientské části umístěné na několika počítačích implementující uživatelské rozhraní. Aplikační logiku lze přiřadit serveru, klientům nebo mezi nimi sdílet (obrázek 1.3).

Rýže. 1.3.

Architektura aplikací postavená na tomto principu se nazývá klient-server nebo dvouvrstvá. V praxi takové systémy často nejsou klasifikovány jako distribuované, ale formálně je lze považovat za nejjednodušší zástupce distribuovaných systémů.

Vývoj architektury klient-server je třívrstvá architektura, ve které jsou uživatelské rozhraní, aplikační logika a přístup k datům rozděleny do nezávislých komponent systému, které mohou běžet na nezávislých počítačích (obr. 1.4).

Rýže. 1.4.

Požadavek uživatele v takových systémech postupně zpracovává klientská část systému, server aplikační logiky a databázový server. Distribuovaný systém je však obvykle chápán jako systém se složitější architekturou než třívrstvý.

V předchozí kapitole jsme se podívali na těsně provázané víceprocesorové systémy se sdílenou pamětí, sdílenými datovými strukturami jádra a sdíleným fondem, ze kterého jsou volány procesy. Často je však žádoucí alokovat procesory takovým způsobem, aby byly autonomní na operačním prostředí a provozních podmínkách pro účely sdílení zdrojů. Předpokládejme například, že uživatel osobního počítače potřebuje získat přístup k souborům umístěným na větším počítači, ale zároveň si ponechat kontrolu nad osobním počítačem. Ačkoli některé programy, jako je uucp, podporují síťový přenos souborů a další síťové funkce, jejich použití nebude uživateli skryto, protože uživatel si je vědom, že síť používá. Kromě toho je třeba poznamenat, že programy jako textové editory nepracují se smazanými soubory jako s běžnými soubory. Uživatelé by měli mít standardní sadu funkcí systému UNIX a kromě potenciálního omezení výkonu by neměli cítit překračování hranic stroje. Takže například práce systémových funkcí otevírat a číst se soubory na vzdálených počítačích by se neměla lišit od jejich práce se soubory patřícími místním systémům.

Architektura distribuovaného systému je znázorněna na obrázku 13.1. Každý počítač zobrazený na obrázku je samostatná jednotka skládající se z CPU, paměti a periferií. Model se nerozbije, i když počítač nemá lokální souborový systém: musí mít periferní zařízení pro komunikaci s jinými stroji a všechny soubory, které k němu patří, mohou být umístěny na jiném počítači. Fyzická paměť dostupná pro každý stroj je nezávislá na procesech běžících na jiných strojích. V tomto ohledu se distribuované systémy liší od těsně propojených víceprocesorových systémů, o kterých jsme hovořili v předchozí kapitole. V souladu s tím jádro systému na každém stroji funguje nezávisle na vnějších provozních podmínkách distribuovaného prostředí.

Obrázek 13.1. Model systému distribuované architektury

Distribuované systémy, dobře popsané v literatuře, tradičně spadají do následujících kategorií:

Periferní systémy, což jsou skupiny strojů, které mají silnou podobnost a jsou spojeny s jedním (obvykle větším) strojem. Periferní procesory sdílejí svou zátěž s centrálním procesorem a předávají mu všechna volání operačního systému. Cílem periferního systému je zvýšit celkový výkon sítě a poskytnout možnost přidělit procesor jedinému procesu v operačním prostředí UNIX. Systém se spustí jako samostatný modul; Na rozdíl od jiných modelů distribuovaných systémů nemají periferní systémy skutečnou autonomii, s výjimkou případů souvisejících s odbavováním procesů a alokací místní paměti.

Distribuované systémy jako "Newcastle", umožňující vzdálenou komunikaci podle názvů vzdálených souborů v knihovně (název je převzat z článku "The Newcastle Connection" - viz). Smazané soubory mají kusovník (rozlišující název), který ve vyhledávací cestě obsahuje speciální znaky nebo volitelnou komponentu názvu, která předchází kořen systému souborů. Implementace této metody nezahrnuje provádění změn v jádře systému, a proto je jednodušší než ostatní metody popsané v této kapitole, ale méně flexibilní.

Distribuované systémy jsou zcela transparentní, ve kterých standardní rozlišující názvy postačují k odkazování na soubory umístěné na jiných počítačích; je na jádru, aby tyto soubory rozpoznalo jako smazané. Cesty pro vyhledávání souborů specifikované v jejich složených názvech překračují hranice stroje v bodech připojení, bez ohledu na to, kolik takových bodů se vytvoří, když jsou souborové systémy připojeny na disky.

V této kapitole se podíváme na architekturu každého modelu; veškeré poskytnuté informace nejsou založeny na výsledcích konkrétního vývoje, ale na informacích publikovaných v různých technických článcích. To předpokládá, že moduly protokolů a ovladače zařízení jsou zodpovědné za adresování, směrování, řízení toku a detekci a opravu chyb – jinými slovy, že každý model je nezávislý na používané síti. Příklady použití systémových funkcí uvedené v další části pro periferní systémy fungují podobným způsobem pro systémy jako Newcastle a pro zcela transparentní systémy, o kterých bude řeč později; proto je jednou podrobně zvážíme a v částech věnovaných dalším typům systémů se zaměříme především na vlastnosti, které tyto modely odlišují od všech ostatních.

13.1 PERIFERNÍ PROCESORY

Architektura periferního systému je znázorněna na obrázku 13.2. Cílem této konfigurace je zlepšit celkový výkon sítě přerozdělením běžících procesů mezi CPU a periferní procesory. Každý z periferních procesorů nemá k dispozici žádná jiná lokální periferní zařízení kromě těch, která potřebuje ke komunikaci s centrální procesorovou jednotkou. Souborový systém a všechna zařízení jsou k dispozici centrálnímu procesoru. Předpokládejme, že všechny uživatelské procesy jsou prováděny na periferním procesoru a nepřesouvají se mezi periferními procesory; jakmile jsou převedeny na procesor, zůstávají na něm až do dokončení. Periferní procesor obsahuje odlehčenou verzi operačního systému, určenou pro obsluhu lokálních volání do systému, správu přerušení, alokaci paměti, práci se síťovými protokoly a s ovladačem zařízení pro komunikaci s centrálním procesorem.

Když je systém inicializován na centrálním procesoru, jádro načte lokální operační systém na každý z periferních procesorů prostřednictvím komunikačních linek. Jakýkoli proces běžící na periferii je spojen se satelitním procesem patřícím k centrálnímu procesoru (viz); když proces běžící na periferním procesoru volá systémovou funkci, která vyžaduje pouze služby centrálního procesoru, periferní proces komunikuje se svým satelitem a požadavek je odeslán ke zpracování centrálnímu procesoru. Satelitní proces vykonává systémovou funkci a posílá výsledky zpět do periferního procesoru. Vztah mezi periferním procesem a jeho satelitem je podobný vztahu klient-server, kterému jsme se podrobně věnovali v kapitole 11: periferní proces funguje jako klient svého satelitu, který podporuje funkce práce se souborovým systémem. V tomto případě má proces vzdáleného serveru pouze jednoho klienta. V sekci 13.4 se podíváme na procesy serveru s více klienty.

Obrázek 13.2. Konfigurace periferního systému

Obrázek 13.3. Formáty zpráv

Když periferní proces zavolá systémovou funkci, kterou lze zpracovat lokálně, jádro nemusí posílat požadavek satelitnímu procesu. Takže například za účelem získání další paměti může proces zavolat funkci sbrk pro místní spuštění. Pokud jsou však služby centrálního procesoru vyžadovány například pro otevření souboru, jádro zakóduje informace o parametrech předávaných volané funkci a podmínkách provádění procesu do zprávy zaslané satelitnímu procesu (obrázek 13.3). Zpráva obsahuje znak, ze kterého vyplývá, že funkci systému vykonává satelitní proces jménem klienta, parametry předávané funkci a údaje o prostředí provádění procesu (například identifikační kódy uživatelů a skupin), které jsou různé pro různé funkce. Zbytek zprávy jsou data s proměnnou délkou (například název složeného souboru nebo data, která mají být zapsána pomocí funkce write).

Satelitní proces čeká na požadavky od periferního procesu; když je přijat požadavek, dekóduje zprávu, určí typ systémové funkce, provede ji a převede výsledky na odpověď odeslanou perifernímu procesu. Odpověď kromě výsledků provádění systémové funkce zahrnuje chybovou zprávu (pokud existuje), číslo signálu a pole dat s proměnnou délkou obsahující například informace načtené ze souboru. Periferní proces je pozastaven, dokud není přijata odpověď, po jejím obdržení dešifruje a předá výsledky uživateli. Toto je obecné schéma zpracování volání operačního systému; nyní přejděme k podrobnější úvaze o jednotlivých funkcích.

Chcete-li vysvětlit, jak periferní systém funguje, zvažte řadu funkcí: getppid, open, write, fork, exit a signal. Funkce getppid je docela přímočará, protože se zabývá jednoduchými formuláři požadavků a odpovědí, které si vyměňují periferie a CPU. Jádro na periferním procesoru vygeneruje zprávu, která má znaménko, ze kterého vyplývá, že požadovaná funkce je funkce getppid, a odešle požadavek na centrální procesor. Satelitní proces na centrálním procesoru přečte zprávu z periferního procesoru, dešifruje typ systémové funkce, provede ji a získá identifikátor svého rodiče. Poté vygeneruje odpověď a předá ji čekajícímu perifernímu procesu na druhém konci komunikační linky. Když periferní procesor obdrží odpověď, předá ji procesu, který nazývá systémovou funkci getppid. Pokud periferní proces ukládá data (např. ID procesu rodiče) do lokální paměti, nemusí se svým společníkem vůbec komunikovat.

Pokud je zavolána funkce otevřeného systému, periferní proces odešle svému společníkovi zprávu, která obsahuje název souboru a další parametry. Je-li úspěšný, doprovodný proces přidělí index a vstupní bod tabulce souborů, přidělí položku v tabulce deskriptorů souboru uživatele ve svém prostoru a vrátí deskriptor souboru perifernímu procesu. Celou tu dobu na druhém konci komunikační linky čeká periferní proces na odpověď. Nemá k dispozici žádné struktury, které by uchovávaly informace o otevíraném souboru; Deskriptor vrácený příkazem open je ukazatel na položku v doprovodném procesu v tabulce deskriptorů souboru uživatele. Výsledky provedení funkce jsou znázorněny na obrázku 13.4.

Obrázek 13.4. Volání otevřené funkce z periferního procesu

Pokud je provedeno volání systémové funkce zápisu, periferní procesor vygeneruje zprávu sestávající ze znaku funkce zápisu, deskriptoru souboru a množství dat, která mají být zapsána. Z prostoru periferního procesu pak přes komunikační linku kopíruje data do satelitního procesu. Satelitní proces přijatou zprávu dešifruje, načte data z komunikační linky a zapíše je do odpovídajícího souboru (deskriptor obsažený ve zprávě je použit jako ukazatel, na jehož index a záznam v tabulce souborů je použit ); všechny tyto akce se provádějí na centrálním procesoru. Na konci práce odešle satelitní proces perifernímu procesu zprávu, která potvrzuje přijetí zprávy a obsahuje počet bajtů dat, která byla úspěšně zkopírována do souboru. Operace čtení je podobná; satelit informuje periferní proces o počtu skutečně přečtených bytů (v případě čtení dat z terminálu nebo z kanálu se toto číslo nemusí vždy shodovat s množstvím uvedeným v požadavku). Pro provedení jedné nebo druhé funkce může být nutné posílat informační zprávy vícekrát po síti, což je určeno množstvím odeslaných dat a velikostí síťových paketů.

Jedinou funkcí, kterou je třeba změnit při běhu na CPU, je funkce vidlicového systému. Když proces na CPU vykoná tuto funkci, jádro pro něj vybere periferní procesor a odešle zprávu speciálnímu procesu - serveru, který jej informuje, že začne vykládat aktuální proces. Za předpokladu, že server požadavek přijal, jádro použije fork k vytvoření nového periferního procesu a přidělí záznam v tabulce procesů a adresní prostor. Centrální procesor uvolní kopii procesu, který volal funkci vidlice, do periferního procesoru, přepíše nově přidělený adresní prostor, vytvoří místní satelit pro komunikaci s novým periferním procesem a odešle periferii zprávu, aby inicializoval programový čítač pro nový proces. Satelitní proces (na CPU) je potomkem procesu, který se nazývá fork; periferní proces je technicky potomkem procesu serveru, ale logicky je potomkem procesu, který nazval funkci fork. Proces serveru nemá žádné logické spojení s potomkem, když se fork dokončí; jediným úkolem serveru je pomoci vyložit dítě. Díky silnému propojení mezi komponentami systému (periferní procesory nemají autonomii) mají periferní proces a satelitní proces stejný identifikační kód. Vztah mezi procesy je znázorněn na obrázku 13.5: souvislá čára ukazuje vztah rodič-dítě a tečkovaná čára ukazuje vztah mezi vrstevníky.

Obrázek 13.5. Provádění funkce vidlice na CPU

Když proces vykonává funkci vidlice na periferním procesoru, odešle zprávu svému satelitu na CPU, který pak provede celou sekvenci výše popsaných akcí. Družice vybere nový periferní procesor a provede nezbytné přípravy pro vyjmutí obrazu starého procesu: vyšle nadřazenému perifernímu procesu požadavek na přečtení jeho obrazu, načež na druhém konci začne přenos požadovaných dat. komunikačního kanálu. Družice přečte vysílaný obraz a přepíše jej perifernímu potomkovi. Když je stahování obrazu dokončeno, satelitní proces se rozvětví, vytvoří svého potomka na CPU a předá hodnotu programového čítače perifernímu potomkovi, aby ten věděl, ze které adresy má začít provádění. Samozřejmě by bylo lepší, kdyby byl potomek doprovodného procesu přiřazen perifernímu potomkovi jako rodič, ale v našem případě jsou vygenerované procesy schopny běžet na jiných periferních procesorech, nejen na tom, na kterém jsou vytvořeny. Vztah mezi procesy na konci funkce vidlice je znázorněn na obrázku 13.6. Když periferní proces dokončí svou práci, odešle odpovídající zprávu satelitnímu procesu a tím také skončí. Doprovodný proces nemůže zahájit vypnutí.

Obrázek 13.6. Provádění funkce vidlice na periferním procesoru

V multiprocesorových i jednoprocesorových systémech musí proces reagovat na signály stejně: proces buď dokončí provedení funkce systému před kontrolou signálů, nebo naopak po přijetí signálu okamžitě opustí pozastavený stav a náhle přeruší práci systémové funkce, pokud je to v souladu s prioritou, se kterou byl pozastaven. Protože satelitní proces vykonává systémové funkce jménem periferního procesu, musí reagovat na signály v koordinaci s periferním procesem. Pokud na jednoprocesorovém systému signál způsobí, že proces přeruší funkci, doprovodný proces na víceprocesorovém systému by se měl chovat stejným způsobem. Totéž lze říci o případě, kdy signál vyzve proces k ukončení své práce pomocí funkce exit: periferní proces se ukončí a odešle odpovídající zprávu satelitnímu procesu, který se samozřejmě také ukončí.

Když periferní proces zavolá funkci signálního systému, uloží aktuální informace do lokálních tabulek a pošle svému satelitu zprávu, která jej informuje, zda má být specifikovaný signál přijat nebo ignorován. Satelitnímu procesu je jedno, zda zachytí signál nebo výchozí akci. Reakce procesu na signál závisí na třech faktorech (obrázek 13.7): zda signál dorazí, zatímco proces vykonává systémovou funkci, zda je pomocí signálové funkce signalizováno ignorování signálu, zda se signál vyskytuje na na stejném periferním procesoru nebo na nějakém jiném. Pojďme k zvažování různých možností.

algoritmus sighandle / * algoritmus zpracování signálu * /

if (aktuální proces je něčí společník nebo má prototyp)

if (signál je ignorován)

if (signál přišel během provádění systémové funkce)

dát signál před satelitní proces;

poslat signální zprávu perifernímu procesu;

jinak (/ * periferní proces * /

/ * zda byl signál přijat během provádění systémové funkce nebo ne * /

poslat signál do satelitního procesu;

algoritmus satellite_end_of_syscall / * ukončení systémové funkce volané periferním procesem * /

vstupní informace: chybí

otisk: žádný

if (bylo přijato přerušení během provádění systémové funkce)

odeslat zprávu o přerušení, signál perifernímu procesu;

else / * provádění systémové funkce nebylo přerušeno * /

odeslat odpověď: povolit příznak ukazující příchod signálu;

Obrázek 13.7. Zpracování signálu v periferním systému

Předpokládejme, že periferní proces pozastavil svou práci, zatímco satelitní proces jeho jménem vykonává systémovou funkci. Pokud se signál vyskytuje jinde, satelitní proces jej detekuje dříve než periferní proces. Jsou možné tři případy.

1. Pokud se satelitní proces během čekání na nějakou událost nedostal do pozastaveného stavu, ze kterého by po přijetí signálu vystoupil, provede funkci systému až do konce, odešle výsledky provedení perifernímu procesu a zobrazí jaký signál přijal.

2. Pokud proces dostane pokyn ignorovat tento typ signálu, satelit bude nadále sledovat algoritmus provádění systémové funkce, aniž by opustil pozastavený stav pomocí longjmp. V odpovědi zaslané perifernímu procesu nebude žádná zpráva o příjmu signálu.

3. Pokud satelitní proces při příjmu signálu přeruší provádění systémové funkce (pomocí longjmp), informuje o tom periferní proces a sdělí mu číslo signálu.

Periferní proces hledá informace o příjmu signálů v přijaté odpovědi a pokud existují, zpracuje signály před ukončením funkce systému. Chování procesu ve víceprocesorovém systému tedy přesně odpovídá jeho chování v jednoprocesorovém systému: buď se ukončí, aniž by opustil režim jádra, nebo zavolá vlastní funkci zpracování signálu, nebo signál ignoruje a úspěšně dokončí funkci systému.

Obrázek 13.8. Přerušení během provádění systémové funkce

Předpokládejme například, že periferní proces zavolá funkci čtení z terminálu připojeného k centrálnímu procesoru a pozastaví svou práci, zatímco satelitní proces tuto funkci provede (obrázek 13.8). Pokud uživatel stiskne klávesu přerušení, jádro CPU vyšle signál satelitnímu procesu. Pokud byl satelit v pozastaveném stavu a čekal na část dat z terminálu, okamžitě tento stav opustí a ukončí funkci čtení. Ve své odpovědi na požadavek od periferního procesu satelit poskytne chybový kód a číslo signálu odpovídající přerušení. Periferní proces analyzuje odezvu, a protože zpráva říká, že došlo k přerušení, vyšle signál sám sobě. Před ukončením funkce čtení periferní jádro zkontroluje signalizaci, detekuje signál přerušení ze satelitního procesu a zpracuje jej jako obvykle. Pokud periferní proces v důsledku přijetí signálu přerušení ukončí svou práci pomocí funkce exit, tato funkce se postará o zabití satelitního procesu. Pokud periferní proces zachytí signály přerušení, zavolá uživatelem definovanou funkci zpracování signálu a po ukončení funkce čtení vrátí uživateli chybový kód. Na druhou stranu, pokud satelit vykonává funkci statistického systému jménem periferního procesu, nepřeruší její provádění, když přijme signál (funkce statistik zaručeně ukončí jakoukoli pauzu, protože má omezenou dobu čekání na zdroje ). Satelit dokončí provádění funkce a vrátí číslo signálu perifernímu procesu. Periferní proces vyšle signál sám sobě a přijme ho na výstupu ze systémové funkce.

Pokud se na periferním procesoru objeví signál během provádění systémové funkce, bude periferní proces ve tmě, zda se brzy vrátí k řízení ze satelitního procesu, nebo ten přejde do pozastaveného stavu na dobu neurčitou. Periferní proces odešle družici speciální zprávu, která ji informuje o výskytu signálu. Jádro na CPU zprávu dešifruje a vyšle satelitu signál, jehož reakce na příjem signálu je popsána v předchozích odstavcích (abnormální ukončení vykonávání funkce nebo její dokončení). Periferní proces nemůže odeslat zprávu satelitu přímo, protože satelit je zaneprázdněn prováděním systémové funkce a nečte data z komunikační linky.

S odkazem na příklad čtení je třeba poznamenat, že periferní proces netuší, zda jeho společník čeká na vstup z terminálu nebo provádí jiné akce. Periferní proces odešle signální zprávu satelitu: pokud je satelit v pozastaveném stavu s přerušitelnou prioritou, okamžitě tento stav opustí a ukončí funkci systému; jinak se funkce přenese do úspěšného dokončení.

Nakonec zvažte případ příchodu signálu v době, která není spojena s prováděním systémové funkce. Pokud signál pochází z jiného procesoru, satelit jej nejprve přijme a odešle signálovou zprávu perifernímu procesu, ať už se signál týká periferního procesu nebo ne. Periferní jádro zprávu dešifruje a vyšle signál procesu, který na něj zareaguje obvyklým způsobem. Pokud signál pochází z periferního procesoru, proces provede standardní akce, aniž by se uchýlil ke službám svého satelitu.

Když periferní proces odešle signál dalším periferním procesům, zakóduje zprávu o volání deaktivace a odešle ji satelitnímu procesu, který lokálně provede volanou funkci. Pokud je některý z procesů, pro který je signál určen, umístěn na jiných periferních procesorech, jejich satelity signál přijmou (a zareagují na něj výše popsaným způsobem).

13.2 TYP KOMUNIKACE NEWCASTLE

V předchozí části jsme uvažovali o typu těsně propojeného systému, který se vyznačuje odesíláním všech volání funkcí subsystému správy souborů, které vznikají na periferním procesoru, na vzdálený (centrální) procesor. Nyní přejdeme k úvahám o systémech se slabším připojením, které se skládají ze strojů, které volají soubory umístěné na jiných strojích. Například v síti osobních počítačů a pracovních stanic uživatelé často přistupují k souborům umístěným na velkém počítači. V dalších dvou částech se podíváme na konfigurace systému, ve kterých jsou všechny funkce systému vykonávány v lokálních subsystémech, ale zároveň je možné přistupovat k souborům (prostřednictvím funkcí subsystému správy souborů) umístěným na jiných strojích.

Tyto systémy používají k identifikaci smazaných souborů jednu z následujících dvou cest. Na některých systémech je ke složenému názvu souboru přidán speciální znak: složka názvu, která předchází tomuto znaku, identifikuje počítač, zbytek názvu je soubor na tomto počítači. Tedy například to příznačné jméno

"sftig! / fs1 / mjb / rje"

identifikuje soubor "/ fs1 / mjb / rje" na stroji "sftig". Toto schéma identifikace souborů se řídí konvencí uucp pro přenos souborů mezi systémy podobnými UNIXu. V jiném schématu jsou smazané soubory identifikovány přidáním speciální předpony k názvu, například:

/../sftig/fs1/mjb/rje

kde "/../" je předpona označující, že soubor je smazán; druhá součást názvu souboru je jméno vzdáleného počítače. Toto schéma používá známou syntaxi názvů souborů UNIX, takže na rozdíl od prvního schématu se uživatelské programy nemusejí přizpůsobovat používání názvů s neobvyklou konstrukcí (viz).

Obrázek 13.9. Formulování požadavků na souborový server (procesor)

Zbytek této části budeme věnovat modelu systému využívajícího odkaz Newcastle, ve kterém se jádro nezabývá rozpoznáváním smazaných souborů; tato funkce je zcela přiřazena podprogramům ze standardní knihovny C, které v tomto případě hrají roli systémového rozhraní. Tyto rutiny analyzují první složku názvu souboru, která v obou popsaných metodách identifikace obsahuje znak odlehlosti souboru. Toto je odchylka od rutiny, ve které knihovní rutiny neanalyzují názvy souborů. Obrázek 13.9 ukazuje, jak jsou formulovány požadavky na souborový server. Pokud je soubor lokální, jádro místního systému zpracuje požadavek normálně. Zvažte opačný případ:

otevřít ("/../ sftig / fs1 / mjb / rje / soubor", O_RDONLY);

Otevřený podprogram v knihovně C analyzuje první dvě složky rozlišujícího názvu souboru a ví, že má hledat soubor na vzdáleném počítači "sftig". Aby měl podprogram informaci o tom, zda měl proces dříve spojení s daným strojem, spustí speciální strukturu, ve které si tuto skutečnost zapamatuje a v případě záporné odpovědi naváže spojení se souborovým serverem běžícím na vzdáleném stroji. Když proces formuluje svůj první požadavek na vzdálené zpracování, vzdálený server požadavek potvrdí, v případě potřeby zaznamená do polí uživatelských a skupinových identifikačních kódů a vytvoří satelitní proces, který bude jednat jménem klientského procesu.

Pro splnění požadavků klienta musí mít satelit stejná oprávnění k souboru na vzdáleném počítači jako klient. Jinými slovy, uživatel „mjb“ musí mít stejná přístupová práva ke vzdáleným i lokálním souborům. Bohužel je možné, že identifikační kód klienta „mjb“ se může shodovat s identifikačním kódem jiného klienta na vzdáleném počítači. Správci systému na počítačích běžících v síti by tedy měli buď zajistit, aby byl každému uživateli přidělen identifikační kód, který je jedinečný pro celou síť, nebo provést konverzi kódu v době formulování požadavku na síťovou službu. Pokud tak neučiníte, bude mít doprovodný proces práva jiného klienta na vzdáleném počítači.

Delikátnějším problémem je získání práv superuživatele ve vztahu k práci se vzdálenými soubory. Na jedné straně by klient superuživatele neměl mít stejná práva ke vzdálenému systému, aby nedošlo ke zkreslení ovládacích prvků zabezpečení vzdáleného systému. Na druhou stranu některé programy, pokud jim nebudou udělena práva superuživatele, prostě nebudou moci fungovat. Příkladem takového programu je program mkdir (viz kapitola 7), který vytvoří nový adresář. Vzdálený systém by klientovi nedovolil vytvořit nový adresář, protože práva superuživatele nejsou při mazání účinná. Problém vytváření vzdálených adresářů slouží jako vážný důvod pro revizi systémové funkce mkdir směrem k rozšíření jejích možností v automatickém navazování všech spojení nezbytných pro uživatele. Stále je však běžným problémem, že programy setuid (jako je program mkdir) získávají oprávnění superuživatele nad vzdálenými soubory. Možná nejlepším řešením tohoto problému by bylo nastavit další charakteristiky pro soubory, které popisují přístup k nim vzdálenými superuživateli; bohužel by to vyžadovalo změny ve struktuře indexu disku (ve smyslu přidávání nových polí) a ve stávajících systémech by to způsobilo příliš mnoho nepořádku.

Pokud je otevřený podprogram úspěšný, místní knihovna o tom zanechá odpovídající poznámku v uživatelsky přístupné struktuře obsahující adresu síťového uzlu, ID procesu satelitního procesu, deskriptor souboru a další podobné informace. Rutiny pro čtení a zápis knihovny určují na základě deskriptoru souboru, zda je soubor smazán, a pokud ano, pošlou zprávu na satelit. Klientský proces komunikuje se svým společníkem ve všech případech přístupu k funkcím systému, které vyžadují služby vzdáleného stroje. Pokud proces přistupuje ke dvěma souborům umístěným na stejném vzdáleném počítači, používá jeden satelit, ale pokud jsou soubory umístěny na různých počítačích, jsou již použity dva satelity: jeden na každém počítači. Dva satelity se také používají, když dva procesy přistupují k souboru na vzdáleném počítači. Vyvoláním systémové funkce přes satelit proces vygeneruje zprávu, která obsahuje číslo funkce, název vyhledávací cesty a další potřebné informace, podobné těm, které jsou obsaženy ve struktuře zprávy v systému s periferními procesory.

Mechanismus provádění operací v aktuálním adresáři je složitější. Když proces vybere vzdálený adresář jako aktuální, rutina knihovny odešle zprávu satelitu, který změní aktuální adresář, a rutina si zapamatuje, že adresář je smazán. Ve všech případech, kdy název vyhledávací cesty začíná jiným znakem než lomítkem (/), podprogram odešle název vzdálenému počítači, kam jej satelitní proces nasměruje z aktuálního adresáře. Pokud je aktuální adresář lokální, rutina jednoduše předá název vyhledávací cesty jádru lokálního systému. Funkce chroot systému ve vzdáleném adresáři je podobná, ale pro místní jádro zůstává bez povšimnutí; přísně vzato, proces může tuto operaci ignorovat, protože její provedení zaznamená pouze knihovna.

Když proces zavolá fork, příslušná knihovní rutina odešle zprávy každému satelitu. Satelitní procesy se rozvětvují a odesílají svá podřízená ID nadřazenému klientovi. Klientský proces spouští systémovou funkci fork, která přenáší řízení na potomka, který vytvoří; místní dítě je v dialogu se vzdáleným satelitním potomkem, jehož adresy jsou uloženy rutinou knihovny. Tato interpretace funkce vidlice usnadňuje satelitním procesům ovládat otevřené soubory a aktuální adresáře. Když proces práce se vzdálenými soubory skončí (zavoláním funkce exit), podprogram odešle zprávy všem svým vzdáleným satelitům, takže když zprávu přijmou, udělají totéž. Některé aspekty implementace funkcí exec a exit systému jsou diskutovány ve cvičeních.

Výhodou propojení Newcastle je, že přístup procesu ke vzdáleným souborům se stává transparentním (neviditelným pro uživatele), aniž by bylo nutné provádět jakékoli změny v jádře systému. Tento vývoj má však řadu nevýhod. Za prvé, během jeho implementace je možný pokles výkonu systému. Díky použití rozšířené knihovny C se velikost paměti používané každým procesem zvyšuje, i když proces nepřistupuje ke vzdáleným souborům; knihovna duplikuje funkce jádra a vyžaduje více místa v paměti. Zvětšením velikosti procesů se prodlouží doba spouštění a může vzniknout více sporů o paměťové zdroje, čímž se vytvoří podmínky pro častější vykládání a stránkování úloh. Lokální požadavky se budou vyřizovat pomaleji kvůli prodloužení doby trvání každého volání do jádra a zpomalit se může i zpracování vzdálených požadavků, zvyšují se náklady na jejich odesílání po síti. Dodatečné zpracování vzdálených požadavků na uživatelské úrovni zvyšuje počet přepínání kontextu, vykládání a swapování. A konečně, aby bylo možné přistupovat ke vzdáleným souborům, programy musí být rekompilovány pomocí nových knihoven; staré programy a dodané objektové moduly bez něj nebudou moci pracovat se vzdálenými soubory. Všechny tyto nevýhody v systému popsaném v další části chybí.

13.3 „TRANSPARENTNÍ“ DISTRIBUOVANÉ SOUBOROVÉ SYSTÉMY

Termín „transparentní alokace“ znamená, že uživatelé na jednom počítači mohou přistupovat k souborům na jiném stroji, aniž by si uvědomovali, že překračují hranice stroje, stejně jako jsou na svém stroji, když přecházejí z jednoho souborového systému na jiný a procházejí body připojení. Názvy, kterými procesy odkazují na soubory umístěné na vzdálených počítačích, jsou podobné názvům místních souborů: nejsou v nich žádné rozlišovací znaky. V konfiguraci zobrazené na obrázku 13.10 je adresář „/ usr / src“ patřící ke stroji B „připojen“ do adresáře „/ usr / src“ patřícího ke stroji A. stejný systémový zdrojový kód, který se tradičně nachází v „/ adresář usr / src". Uživatelé běžící na počítači A mohou přistupovat k souborům umístěným na počítači B pomocí obvyklé syntaxe zápisu názvů souborů (například: "/usr/src/cmd/login.c") a jádro samo rozhoduje, zda je soubor vzdálený nebo lokální. . Uživatelé běžící na počítači B mají přístup ke svým místním souborům (nevědí, že uživatelé počítače A mají přístup ke stejným souborům), ale zase nemají přístup k souborům umístěným na počítači A. Samozřejmě jsou možné i další možnosti, zejména ty, ve kterých jsou všechny vzdálené systémy připojeny ke kořenovému adresáři místního systému, takže uživatelé mají přístup ke všem souborům na všech systémech.

Obrázek 13.10. Souborové systémy po vzdáleném připojení

Podobnosti mezi připojováním lokálních souborových systémů a umožněním přístupu ke vzdáleným souborovým systémům vedly k přizpůsobení funkce připojení vzdáleným souborovým systémům. V tomto případě má jádro k dispozici tabulku pro připojení rozšířeného formátu. Spuštěním funkce připojení jádro organizuje síťové připojení se vzdáleným počítačem a ukládá informace charakterizující toto připojení do tabulky připojení.

Zajímavý problém souvisí s názvy cest, které obsahují „...“. Pokud proces vytvoří aktuální adresář ze vzdáleného souborového systému, pak použití znaků „..“ v názvu s větší pravděpodobností vrátí proces do místního souborového systému, místo aby přistupoval k souborům nad aktuálním adresářem. Vraťme se znovu k obrázku 13.10 a všimněte si, že když proces patřící k počítači A, který předtím vybral aktuální adresář "/ usr / src / cmd" umístěný ve vzdáleném systému souborů, provede příkaz

aktuální adresář bude kořenový adresář stroje A, nikoli stroje B. Algoritmus namei v jádře vzdáleného systému po obdržení sekvence znaků „..“ zkontroluje, zda je volající proces agentem klientského procesu a pokud ano, nastaví, zda klient zachází s aktuálním pracovním adresářem jako s kořenem vzdáleného souborového systému.

Komunikace se vzdáleným strojem má jednu ze dvou forem: vzdálené volání procedury nebo vzdálené volání systémové funkce. V prvním formuláři každá procedura jádra zabývající se indexy zkontroluje, zda index ukazuje na vzdálený soubor, a pokud ano, odešle vzdálenému počítači požadavek na provedení zadané operace. Toto schéma přirozeně zapadá do abstraktní struktury podpory souborových systémů různých typů, popsané v závěrečné části kapitoly 5. Přístup ke vzdálenému souboru tak může iniciovat přenos několika zpráv po síti, jejichž počet je určeno počtem implikovaných operací se souborem, s odpovídajícím zvýšením doby odezvy na požadavek, s přihlédnutím k čekací době akceptované v síti. Každá sada vzdálených operací obsahuje minimálně akce pro zamykání indexu, počítání referencí atd. Za účelem vylepšení modelu byla navržena různá optimalizační řešení související s kombinací několika operací do jednoho dotazu (zprávy) a ukládáním nejdůležitějších dat do vyrovnávací paměti (cm. ).

Obrázek 13.11. Otevření vzdáleného souboru

Zvažte proces, který otevře vzdálený soubor "/usr/src/cmd/login.c", kde "src" je bod připojení. Analýzou názvu souboru (pomocí schématu namei-iget) jádro zjistí, že soubor je smazán, a odešle hostitelskému počítači požadavek na získání zamčeného indexu. Po obdržení požadované odpovědi vytvoří místní jádro v paměti kopii indexu odpovídající vzdálenému souboru. Poté jádro zkontroluje potřebná přístupová práva k souboru (například pro čtení) odesláním další zprávy na vzdálený počítač. Otevřený algoritmus pokračuje plně v souladu s plánem nastíněným v kapitole 5 a podle potřeby odesílá zprávy vzdálenému počítači, dokud není algoritmus dokončen a index není uvolněn. Vztah mezi datovými strukturami jádra po dokončení otevřeného algoritmu je znázorněn na obrázku 13.11.

Pokud klient zavolá funkci čtení systému, klientské jádro uzamkne lokální index, vydá zámek na vzdáleném indexu, požadavek na čtení, zkopíruje data do místní paměti, vydá požadavek na uvolnění vzdáleného indexu a uvolní lokální index. . Toto schéma je v souladu se sémantikou stávajícího jednoprocesorového jádra, ale frekvence používání sítě (vícenásobné volání každé systémové funkce) snižuje výkon celého systému. Pro snížení toku zpráv v síti je však možné spojit více operací do jednoho požadavku. V příkladu s funkcí čtení může klient poslat serveru jeden obecný požadavek "čtení" a server se sám rozhodne uchopit a uvolnit index, když je spuštěn. Snížení síťového provozu lze také dosáhnout použitím vzdálených vyrovnávacích pamětí (jak jsme diskutovali výše), ale je třeba dbát na to, aby funkce systémových souborů využívající tyto vyrovnávací paměti byly prováděny správně.

Při druhé formě komunikace se vzdáleným počítačem (volání funkce vzdáleného systému) místní jádro zjistí, že systémová funkce souvisí se vzdáleným souborem, a odešle parametry uvedené ve svém volání vzdálenému systému, který provede a vrátí výsledky klientovi. Klientský stroj obdrží výsledky provedení funkce a opustí stav volání. Většinu systémových funkcí lze provést pomocí pouze jednoho síťového požadavku a přijetí odpovědi po přiměřené době, ale ne všechny funkce do tohoto modelu zapadají. Takže například po přijetí určitých signálů jádro vytvoří soubor pro proces nazvaný „core“ (kapitola 7). Vytvoření tohoto souboru není spojeno s konkrétní funkcí systému, ale skončí provedením několika operací, jako je vytvoření souboru, kontrola oprávnění a provedení série zápisů.

V případě funkce otevřeného systému obsahuje požadavek na provedení funkce odeslaný na vzdálený počítač část názvu souboru, která zbyla po vyloučení komponent názvu vyhledávací cesty, které odlišují vzdálený soubor, a také různé příznaky. V předchozím příkladu otevření souboru "/usr/src/cmd/login.c" jádro odešle jméno "cmd / login.c" vzdálenému počítači. Zpráva také obsahuje přihlašovací údaje, jako jsou identifikační kódy uživatelů a skupin, které jsou nutné k ověření oprávnění k souboru na vzdáleném počítači. Pokud je od vzdáleného počítače přijata odpověď označující úspěšnou funkci otevření, místní jádro načte volný index v paměti místního počítače a označí jej jako index vzdáleného souboru, uloží informace o vzdáleném počítači a vzdáleném indexu a rutinně přiděluje nový záznam v tabulce souborů. Ve srovnání se skutečným indexem na vzdáleném počítači je index vlastněný místním počítačem formální a nenarušuje konfiguraci modelu, která je v podstatě stejná jako konfigurace použitá při volání vzdálené procedury (obrázek 13.11). Pokud funkce volaná procesem přistupuje ke vzdálenému souboru pomocí svého deskriptoru, místní jádro ví z (lokálního) indexu, že soubor je vzdálený, zformuluje požadavek, který obsahuje volanou funkci, a odešle ho vzdálenému počítači. Požadavek obsahuje ukazatel na vzdálený index, pomocí kterého může satelitní proces identifikovat samotný vzdálený soubor.

Po obdržení výsledku provedení jakékoli systémové funkce se jádro může uchýlit ke službám speciálního programu, aby jej zpracovalo (po jehož dokončení jádro dokončí práci s funkcí), protože lokální zpracování výsledků používané v jednoprocesorovém systému není vždy vhodný pro systém s několika procesory. V důsledku toho jsou možné změny v sémantice systémových algoritmů zaměřené na poskytování podpory pro provádění funkcí vzdáleného systému. Zároveň však v síti cirkuluje minimální tok zpráv, což zajišťuje minimální dobu odezvy systému na příchozí požadavky.

13.4 DISTRIBUOVANÝ MODEL BEZ PROCESŮ PŘENOSU

Použití přenosových procesů (satelitních procesů) v transparentním distribuovaném systému usnadňuje sledování smazaných souborů, ale procesní tabulka vzdáleného systému je přetížena satelitními procesy, které jsou většinu času nečinné. V jiných schématech se ke zpracování vzdálených požadavků používají speciální serverové procesy (viz a). Vzdálený systém má sadu (pool) serverových procesů, které čas od času přiřazuje ke zpracování příchozích vzdálených požadavků. Po zpracování požadavku se proces serveru vrátí do fondu a přejde do stavu připraveného ke zpracování dalších požadavků. Server neukládá uživatelský kontext mezi dvěma voláními, protože může zpracovávat požadavky z několika procesů najednou. Každá zpráva přicházející z klientského procesu proto musí obsahovat informace o prostředí, v němž se provádí, konkrétně: identifikační kódy uživatele, aktuální adresář, signály atd. funkce.

Když proces otevře vzdálený soubor, vzdálené jádro přiřadí index pro následné odkazy na soubor. Lokální počítač udržuje vlastní tabulku deskriptorů souborů, tabulku souborů a tabulku indexů s běžnou sadou záznamů se záznamem tabulky indexů identifikujícím vzdálený počítač a vzdálený index. V případech, kdy systémová funkce (například čtení) používá deskriptor souboru, jádro odešle zprávu ukazující na dříve přiřazený vzdálený index a přenese informace související s procesem: identifikační kód uživatele, maximální velikost souboru atd. stroj má má k dispozici serverový proces, interakce s klientem má formu popsanou výše, spojení mezi klientem a serverem je však navázáno pouze po dobu fungování systému.

Použití serverů místo satelitních procesů může ztížit správu datového provozu, signálů a vzdálených zařízení. Velké množství požadavků na vzdálený počítač při absenci dostatečného počtu serverů by mělo být řazeno do fronty. To vyžaduje protokol vyšší vrstvy, než jaký se používá v hlavní síti. V satelitním modelu je naopak eliminováno přesycení, protože všechny požadavky klientů jsou zpracovávány synchronně. Klient může mít nejvýše jeden nevyřízený požadavek.

Zpracování signálů, které přerušují provádění systémové funkce, je také komplikované při použití serverů, protože vzdálený stroj musí hledat vhodný server obsluhující provádění funkce. Je dokonce možné, že z důvodu vytíženosti všech serverů čeká na zpracování požadavek na systémovou funkci. Podmínky pro vznik konkurence také nastávají, když server vrátí výsledek funkce systému volajícímu procesu a odpověď serveru zahrnuje odeslání odpovídající signalizační zprávy přes síť. Každá zpráva musí být označena, aby ji vzdálený systém mohl rozpoznat a v případě potřeby ukončit procesy serveru. Při použití satelitů je automaticky identifikován proces, který řeší vyřízení požadavku klienta a v případě příchodu signálu není složité zkontrolovat, zda byl požadavek vyřízen či nikoliv.

A konečně, pokud systémová funkce volaná klientem způsobí pozastavení serveru na dobu neurčitou (například při čtení dat ze vzdáleného terminálu), server nemůže zpracovat další požadavky na uvolnění fondu serverů. Pokud na vzdálená zařízení přistupuje několik procesů najednou a počet serverů je shora omezen, dochází k poměrně hmatatelnému úzkému hrdlu. To se u satelitů nestává, protože každému klientskému procesu je přidělen satelit. Další problém s používáním serverů pro vzdálená zařízení bude popsán ve cvičení 13.14.

Navzdory výhodám, které použití satelitních procesů poskytuje, se potřeba volných záznamů v tabulce procesů v praxi stává tak akutní, že ve většině případů jsou pro zpracování vzdálených požadavků stále využívány služby serverových procesů.

Obrázek 13.12. Koncepční diagram interakce se vzdálenými soubory na úrovni jádra

13.5 ZÁVĚRY

V této kapitole jsme zvažovali tři schémata pro práci se soubory umístěnými na vzdálených počítačích, přičemž se vzdáleným souborovým systémem nakládáme jako s rozšířením lokálního. Architektonické rozdíly mezi těmito uspořádáními jsou znázorněny na obrázku 13.12. Všechny se zase od víceprocesorových systémů popsaných v předchozí kapitole liší tím, že zde procesory nesdílejí fyzickou paměť. Periferní procesorový systém se skládá z těsně propojené sady procesorů, které sdílejí souborové prostředky centrálního procesoru. Připojení typu Newcastle poskytuje skrytý („transparentní“) přístup ke vzdáleným souborům, nikoli však pomocí jádra operačního systému, ale pomocí speciální knihovny C. Z tohoto důvodu musí být všechny programy, které mají v úmyslu používat tento typ odkazu, překompilovány, což je obecně vážná nevýhoda tohoto schématu. Vzdálenost souboru je indikována pomocí speciální sekvence znaků popisujících stroj, na kterém je soubor umístěn, a to je další faktor omezující přenositelnost programů.

V transparentních distribuovaných systémech se pro přístup ke vzdáleným souborům používá modifikace funkce systému připojení. Indexy na lokálním systému jsou označeny jako vzdálené soubory a lokální jádro odešle zprávu vzdálenému systému popisující požadovanou funkci systému, její parametry a vzdálený index. Komunikace v „transparentním“ distribuovaném systému je podporována ve dvou formách: ve formě volání vzdálené procedury (na vzdálený stroj je odeslána zpráva obsahující seznam operací spojených s indexem) a ve formě volání na funkci vzdáleného systému (zpráva popisuje požadovanou funkci). Závěrečná část kapitoly pojednává o problémech souvisejících se zpracováním vzdálených požadavků pomocí satelitních procesů a serverů.

13.6 CVIČENÍ

*1. Popište implementaci funkce výstupního systému v systému s periferními procesory. Jaký je rozdíl mezi tímto případem a tím, kdy proces skončí po přijetí nezachyceného signálu? Jak by mělo jádro vypsat obsah paměti?

2. Procesy nemohou ignorovat signály SIGKILL; Vysvětlete, co se stane v periferním systému, když proces přijme takový signál.

* 3. Popište implementaci systémové funkce exec na systému s periferními procesory.

*4. Jak by měl centrální procesor rozdělit procesy mezi periferní procesory, aby vyrovnal celkovou zátěž?

*5. Co se stane, když periferní procesor nemá dostatek paměti pro uložení všech procesů, které jsou na něj přeneseny? Jak by mělo probíhat vykládání a přehazování procesů v síti?

6. Zvažte systém, ve kterém jsou požadavky na vzdálený souborový server odesílány, pokud je v názvu souboru nalezena speciální předpona. Nechte proces volat execl ("/../ sftig / bin / sh", "sh", 0); Spustitelný soubor je na vzdáleném počítači, ale musí běžet na místním systému. Vysvětlete, jak je vzdálený modul migrován do místního systému.

7. Pokud administrátor potřebuje přidat nové stroje do stávajícího systému s připojením jako Newcastle, jaký je pak nejlepší způsob, jak o tom informovat moduly knihovny C?

*osm. Během provádění funkce exec jádro přepíše adresový prostor procesu, včetně tabulek knihoven používaných odkazem Newcastle ke sledování odkazů na vzdálené soubory. Po provedení funkce si proces musí zachovat možnost přístupu k těmto souborům pomocí jejich starých deskriptorů. Popište implementaci tohoto bodu.

*devět. Jak je ukázáno v sekci 13.2, vyvolání funkce ukončovacího systému na systémech s připojením Newcastle má za následek odeslání zprávy do doprovodného procesu, což jej přinutí ukončit. To se provádí na úrovni knihovních rutin. Co se stane, když místní proces přijme signál, který mu říká, aby skončil v režimu jádra?

*deset. V systému s odkazem Newcastle, kde jsou vzdálené soubory identifikovány předponou názvu se speciální předponou, jak může uživatel, který zadá „..“ (nadřazený adresář) jako komponentu názvu souboru, procházet vzdáleným bodem připojení?

11. Z kapitoly 7 víme, že různé signály způsobí, že proces vysype obsah paměti do aktuálního adresáře. Co by se mělo stát, pokud aktuální adresář pochází ze vzdáleného systému souborů? Jakou odpověď byste dali, kdyby systém používal vztah jako Newcastle?

*12. Jaké důsledky by to mělo pro místní procesy, kdyby byly ze systému odstraněny všechny satelitní nebo serverové procesy?

*13. Zvažte, jak implementovat linkový algoritmus v transparentním distribuovaném systému, jehož parametry mohou být dva vzdálené názvy souborů a také algoritmus exec spojený s prováděním několika interních operací čtení. Zvažte dvě formy komunikace: vzdálené volání procedury a vzdálené volání systémové funkce.

*čtrnáct. Při přístupu k zařízení může proces serveru vstoupit do pozastaveného stavu, ze kterého jej vyjme ovladač zařízení. Přirozeně, pokud je počet serverů omezený, systém již nebude schopen uspokojit požadavky místního počítače. Vymyslete spolehlivé schéma, podle kterého nejsou všechny procesy serveru pozastaveny při čekání na dokončení I/O souvisejících se zařízením. Funkce systému se neukončí, pokud jsou všechny servery zaneprázdněny.

Obrázek 13.13. Konfigurace terminálového serveru

*15. Když se uživatel přihlásí do systému, disciplína terminálové linky ukládá informaci, že terminál je operátorský terminál, který vede skupinu procesů. Z tohoto důvodu, když uživatel stiskne klávesu "break" na terminálové klávesnici, všechny procesy ve skupině obdrží signál přerušení. Zvažte konfiguraci systému, ve které jsou všechny terminály fyzicky připojeny k jednomu stroji, ale registrace uživatele je logicky implementována na jiných strojích (obrázek 13.13). V každém případě systém vytvoří proces getty pro vzdálený terminál. Pokud jsou požadavky na vzdálený systém zpracovávány sadou serverových procesů, mějte na paměti, že po provedení otevřené procedury server přestane čekat na připojení. Po dokončení funkce otevření se server vrátí zpět do fondu serverů a přeruší své připojení k terminálu. Jak je signál přerušení spuštěn stisknutím tlačítka "break" odeslán na adresy procesů zařazených ve stejné skupině?

*16. Sdílení paměti je funkce vlastní lokálním počítačům. Z logického hlediska lze alokaci společné oblasti fyzické paměti (lokální nebo vzdálené) provádět pro procesy patřící různým strojům. Popište implementaci tohoto bodu.

* 17. Proces stránkování a stránkovací algoritmy popsané v kapitole 9 předpokládají použití místního pageru. Jaké změny by měly být provedeny v těchto algoritmech, aby byly schopny podporovat zařízení pro vzdálené vykládání?

*osmnáct. Předpokládejme, že vzdálený počítač (nebo síť) zaznamená fatální havárii a protokol místní síťové vrstvy tuto skutečnost zaznamená. Vytvořte schéma obnovy pro místní systém, který bude odesílat požadavky na vzdálený server. Kromě toho vytvořte schéma obnovy pro serverový systém, který ztratil kontakt s klienty.

*19. Když proces přistupuje ke vzdálenému souboru, je možné, že proces při hledání souboru projde více počítačů. Vezměte si jako příklad jméno "/ usr / src / uts / 3b2 / os", kde "/ usr" je adresář patřící k počítači A, "/ usr / src" je bod připojení kořenového adresáře počítače B, " / usr / src / uts / 3b2 "je bod připojení kořenového adresáře počítače C. Procházení více počítačů do konečného cíle se nazývá multihop. Pokud však mezi stroji A a C existuje přímé síťové spojení, bylo by odesílání dat přes stroj B neefektivní. Popište vlastnosti implementace „multishoppingu“ v systému s připojením Newcastle a v „transparentním“ distribuovaném systému.

V současné době mají všechny IS vyvinuté pro komerční účely distribuovanou architekturu, což znamená použití globálních a/nebo lokálních sítí.

Historicky se jako první rozšířila architektura souborového serveru, protože její logika je jednoduchá a na takovou architekturu je nejjednodušší přenést již používané IS. Poté byla transformována do architektury server-klient, kterou lze interpretovat jako její logické pokračování. Moderní systémy používané v globální síti INTERNET se týkají především architektury distribuovaných objektů (viz obr. III‑15 )

IS si lze představit skládající se z následujících komponent (obr. III-16)

III.03.2. a Aplikace souborového serveru.

Jde o historicky první distribuovanou architekturu (obr. III-17). Je organizován velmi jednoduše: na serveru jsou pouze data a vše ostatní patří klientskému počítači. Vzhledem k tomu, že místní sítě jsou poměrně levné a vzhledem k tomu, že s takovou architekturou je aplikační software autonomní, je dnes taková architektura často používána. Dá se říci, že se jedná o variantu architektury klient-server, ve které jsou na serveru umístěny pouze datové soubory. Různé osobní počítače interagují pouze prostřednictvím společného úložiště dat, proto se programy napsané pro jeden počítač nejsnáze přizpůsobují takové architektuře.

Profesionálové:

Výhody architektury souborového serveru:

jednoduchost organizace;

Není v rozporu s nezbytnými požadavky na databázi pro zachování integrity a spolehlivosti.

přetížení sítě;

Nepředvídatelná reakce na požadavek.

Tyto nevýhody se vysvětlují tím, že jakýkoli požadavek na databázi vede k přenosu značného množství informací po síti. Například pro výběr jednoho nebo několika řádků z tabulek se celá tabulka stáhne do klientského počítače a DBMS tam již vybere. Významný síťový provoz je zatížen zejména organizací vzdáleného přístupu k databázi.

III.03.2. b Aplikace typu klient-server.

V tomto případě existuje rozdělení odpovědností mezi server a klient. V závislosti na tom, jak jsou odděleny, rozlišujte Tlustý a tenký klient.

V modelu tenkého klienta se veškerá práce s aplikací a správa dat provádí na serveru. Uživatelské rozhraní v těchto systémech „migruje“ na osobní počítač a samotná softwarová aplikace plní funkce serveru, tzn. spouští všechny aplikační procesy a spravuje data. Model tenkého klienta lze také implementovat tam, kde jsou klienty počítače nebo pracovní stanice. Na síťových zařízeních běží internetový prohlížeč a uživatelské rozhraní implementované v systému.

Hlavní vada modely tenkých klientů - vysoké zatížení serveru a sítě. Všechny výpočty se provádějí na serveru, což může vést ke značnému síťovému provozu mezi klientem a serverem. V moderních počítačích je dostatek výpočetního výkonu, ale v modelu / tenkém klientovi banky se prakticky nepoužívá

Naproti tomu model tlustého klienta využívá výpočetní výkon místních strojů: samotná aplikace je umístěna na klientském počítači. Příkladem tohoto typu architektury jsou ATM systémy, ve kterých je ATM klientem a server je centrálním počítačem obsluhujícím databázi zákaznických účtů.

III.03.2. c Dvou a třívrstvá architektura klient-server.

Všechny výše diskutované architektury jsou dvouvrstvé. Rozlišují mezi úrovní klienta a úrovní serveru. Přísně vzato, IC se skládá ze tří logických úrovní:

· Uživatelská úroveň;

Úroveň aplikace:

· Datová vrstva.

Proto ve dvouvrstvém modelu, kde jsou zapojeny pouze dvě vrstvy, dochází k problémům se škálovatelností a výkonem, pokud je zvolen model tenkého klienta, nebo k problémům se správou systému, pokud je zvolen model tlustého klienta. Těmto problémům se lze vyhnout, pokud použijeme model sestávající ze tří úrovní, kdy dvě z nich jsou servery (obr. III-21).

Datový server

Ve skutečnosti mohou být aplikační server a datový server umístěny na stejném stroji, ale nemohou vzájemně vykonávat funkce. Na třívrstvém modelu je hezké, že logicky odděluje spouštění aplikací a správu dat.

Tabulka III-5 Aplikace různých typů architektur

Architektura	aplikace
Dvouvrstvý tenký klient	1 Starší systémy, ve kterých není vhodné oddělovat spouštění aplikací a správu dat. 2 Výpočetně náročné aplikace s malou správou dat. 3 Aplikace s velkým množstvím dat, ale malým počtem výpočtů.
Dvouvrstvý tlustý klient	1 Aplikace, kde uživatel vyžaduje intenzivní zpracování dat, tedy vizualizaci dat. 2 Aplikace s relativně konstantní sadou uživatelských funkcí aplikované na dobře spravované systémové prostředí.
Třívrstvý server-klient	1 Velké aplikace s buňkami a tisíci klienty 2 Aplikace, ve kterých se často mění data i metody zpracování. 3 Aplikace, které integrují data z více zdrojů.

Tento model je vhodný pro mnoho typů aplikací, ale omezuje vývojáře IS, kteří se musí rozhodnout, kde budou poskytovat služby, poskytovat podporu škálovatelnosti a vyvíjet nástroje pro připojení nových zákazníků.

III.03.2. d Architektura distribuovaných objektů.

Obecnější přístup poskytuje architektura distribuovaných objektů, jejíž hlavními komponentami jsou objekty. Poskytují sadu služeb prostřednictvím svých rozhraní. Jiné objekty odesílají požadavky bez rozlišení mezi klientem a serverem. Objekty mohou být umístěny na různých počítačích v síti a interagovat prostřednictvím middlewaru, podobně jako systémová sběrnice, která umožňuje propojovat různá zařízení a podporovat komunikaci mezi hardwarovými zařízeními.

…

Správce ovladačů ODBC

Řidič 1

Řidič K

DB 1

DB K

Práce s SQL

…

Architektura ODBC obsahuje komponenty:

1. Aplikace (např. IS). Provádí úkoly: požaduje připojení ke zdroji dat, odesílá dotazy SQL do zdroje dat, popisuje oblast úložiště a formát pro dotazy SQL, zpracovává chyby a upozorňuje na ně uživatele, potvrzuje nebo odvolává transakce, požaduje připojení ke zdroji dat. zdroj dat.

2. Správce zařízení. Načítá ovladače na vyžádání aplikací, nabízí jediné rozhraní pro všechny aplikace a administrátorské rozhraní ODBC je stejné a bez ohledu na to, se kterým DBMS bude aplikace komunikovat. Správce ovladačů dodaný společností Microsoft je dynamicky načítaná knihovna (DLL).

3. Ovladač závisí na DBMS. Ovladač ODBC je dynamická knihovna (DLL), která implementuje funkce ODBC a spolupracuje se zdrojem dat. Ovladač je program, který zpracovává požadavek na funkci specifickou pro DBMS (může upravit požadavky v souladu s DBMS) a vrací výsledek do aplikace. Každý DBMS, který podporuje technologii ODBC, musí vývojářům aplikací poskytnout ovladač pro daný DBMS.

4. Zdroj dat obsahuje řídicí informace zadané uživatelem, informace o zdroji dat a používá se pro přístup ke konkrétnímu DBMS. V tomto případě se používají prostředky OS a síťové platformy.

Dynamický model

Tento model předpokládá mnoho aspektů, pro které je v UML použito alespoň 5 diagramů, viz str. 2.04.2- 2.04.5.

Zvažte aspekt řízení. Model řízení doplňuje strukturální modely.

Bez ohledu na to, jak je struktura systému popsána, skládá se ze souboru strukturních jednotek (funkcí nebo objektů). Aby fungovaly jako celek, musí být řízeny a ve statických diagramech nejsou žádné řídicí informace. Řídicí modely navrhují tok řízení mezi systémy.

V softwarových systémech existují dva hlavní typy řízení.

1. Centralizované řízení.

2. Řízení založené na událostech.

Centralizovaná správa může být:

· Hierarchický- na principu "call-return" (takto nejčastěji fungují vzdělávací programy)

· Model dispečera který se používá pro paralelní systémy.

PROTI modely dispečerů předpokládá se, že jednou ze součástí systému je dispečer. Řídí jak spouštění a vypínání systémů, tak koordinaci zbývajících procesů v systému. Procesy mohou běžet vzájemně paralelně. Proces odkazuje na program, podsystém nebo proceduru, která je aktuálně spuštěna. Tento model lze aplikovat i v sekvenčních systémech, kde řídicí program volá jednotlivé podsystémy v závislosti na některých stavových veličinách (přes operátora případ).

Event management předpokládá nepřítomnost jakéhokoli podprogramu odpovědného za řízení. Ovládání se provádí externími událostmi: stisknutím tlačítka myši, stisknutím klávesnice, změnou hodnot senzoru, změnou hodnot časovače atd. Každá externí událost je zakódována a umístěna do fronty událostí. Pokud je poskytnuta reakce na událost ve frontě, je zavolána procedura (podprogram), která provede reakci na tuto událost. Události, na které systém reaguje, mohou nastat buď v jiných subsystémech, nebo ve vnějším prostředí systému.

Příkladem takové správy je organizace aplikací ve Windows.

Všechny dříve popsané strukturální modely lze implementovat pomocí centralizované správy nebo správy založené na událostech.

Uživatelské rozhraní

Při vývoji modelu rozhraní je třeba vzít v úvahu nejen úkoly navrženého softwaru, ale také vlastnosti mozku spojené s vnímáním informací.

III.03.4. a Psychofyzické vlastnosti člověka spojené s vnímáním a zpracováním informací.

Část mozku, kterou lze konvenčně nazvat procesorem vnímání, neustále, bez účasti vědomí, zpracovává příchozí informace, porovnává je s minulou zkušeností a ukládá je do zásoby.

Když vizuální obraz přitáhne naši pozornost, informace, které nás zajímají, se dostanou do krátkodobé paměti. Pokud naše pozornost nebyla přitahována, informace v úložišti zmizí a nahradí je následující části.

V každém okamžiku může být zaměření pozornosti fixováno na jeden bod, takže pokud je nutné současně sledovat několik situací, přesune se zaměření z jednoho sledovaného objektu na druhý. Zároveň je pozornost rozptýlena a některé detaily mohou být přehlédnuty. Je také významné, že vnímání je z velké části založeno na motivaci.

Když změníte rám, mozek se na chvíli zablokuje: zvládne nový obrázek a zvýrazní nejvýznamnější detaily. To znamená, že pokud potřebujete rychlou reakci uživatele, neměli byste obrázky náhle měnit.

Krátkodobá paměť je úzkým hrdlem v systému zpracování informací člověka. Jeho kapacita je 7 ± 2 nepřipojené objekty. Nevyzvednuté informace jsou v něm uloženy nejdéle 30 sekund. Abychom na žádnou pro nás důležitou informaci nezapomněli, většinou si ji opakujeme a aktualizujeme informace v krátkodobé paměti. Při navrhování rozhraní je tedy třeba mít na paměti, že drtivá většina si například obtížně pamatuje a zadává čísla obsahující více než pět číslic na jiné obrazovce.

Přestože kapacita a doba uložení dlouhodobé paměti je neomezená, přístup k informacím není snadný. Mechanismus získávání informací z dlouhodobé paměti je asociativní povahy. Aby se zlepšilo zapamatování informací, jsou vázány na data, která již paměť ukládá, a usnadňuje jejich získání. Vzhledem k tomu, že přístup k dlouhodobé paměti je obtížný, je vhodné očekávat, že si uživatel informace nebude pamatovat, ale na základě toho, že je uživatel pozná.

III.03.4. b Základní kritéria pro hodnocení rozhraní

Četné průzkumy a průzkumy předních firem zabývajících se vývojem softwaru ukázaly, že uživatelé oceňují rozhraní:

1) snadnost zvládnutí a zapamatování – konkrétně posuďte dobu zvládnutí a dobu uchování informací a paměti;

2) rychlost dosahování výsledků při používání systému, která je určena počtem příkazů a nastavení zadaných nebo vybraných myší;

3) subjektivní spokojenost s provozem systému (snadnost použití, únava atd.).

Navíc pro profesionální uživatele, kteří neustále pracují se stejným balíkem, se druhé a třetí kritérium rychle dostane na první místo, a pro neprofesionální uživatele, kteří se softwarem pracují pravidelně a provádějí relativně jednoduché úkoly - první a třetí.

Z tohoto pohledu mají dnes pro profesionální uživatele nejlepší vlastnosti rozhraní s volnou navigací a pro neprofesionální uživatele rozhraní pro přímou manipulaci. Dlouho bylo zjištěno, že při kopírování souborů, za předpokladu, že jsou všechny ostatní věci stejné, většina profesionálů používá shelly jako Far a neprofesionálové používají Windows „drag and drop“.

III.03.4. c Typy uživatelských rozhraní

Rozlišují se následující typy uživatelských rozhraní:

Primitivní

Navigace zdarma

Přímá manipulace.

Rozhraní je primitivní

Primitivní se nazývá rozhraní, které organizuje interakci s uživatelem a používá se v režimu konzoly. Jedinou odchylkou od sekvenčního procesu, který data poskytují, je procházení několika sad dat.

Rozhraní menu.

Na rozdíl od primitivního rozhraní umožňuje uživateli vybrat operaci ze speciálního seznamu zobrazeného programem. Tato rozhraní předpokládají implementaci mnoha scénářů práce, přičemž posloupnost akcí je určena uživateli. Stromová organizace menu naznačuje, že najít položku ve více než dvouúrovňových nabídkách je obtížné.

(Materiál webu http://se.math.spbu.ru)

Úvod.

V dnešní době jsou distribuovány prakticky všechny velké softwarové systémy. Distribuovaný systém- systém, ve kterém není zpracování informací soustředěno na jednom počítači, ale je distribuováno mezi více počítačů. Při návrhu distribuovaných systémů, který má s návrhem softwaru obecně mnoho společného, ​​je stále třeba vzít v úvahu některá specifika.

Existuje šest hlavních charakteristik distribuovaných systémů.

1. Sdílení zdrojů. Distribuované systémy umožňují sdílení jak hardwarových (pevné disky, tiskárny), tak softwarových (soubory, kompilátory) zdrojů.
2. Otevřenost.Je to schopnost rozšířit systém přidáním nových zdrojů.
3. Rovnoběžnost.V distribuovaných systémech může více procesů běžet souběžně na různých počítačích v síti. Tyto procesy mohou interagovat, když jsou spuštěny.
4. Škálovatelnost . Pod škálovatelnost rozumí se možnost přidávání nových vlastností a metod.
5. Odolnost proti chybám. Přítomnost více počítačů umožňuje duplikaci informací a odolnost vůči některým hardwarovým a softwarovým chybám. Distribuované systémy mohou podporovat částečnou funkčnost v případě chyby. K úplnému selhání systému dochází pouze při chybách sítě.
6. Průhlednost.Uživatelům je poskytnut plný přístup ke zdrojům v systému, přičemž jsou jim zároveň skryty informace o rozložení zdrojů v celém systému.

Distribuované systémy mají také řadu nevýhod.

1. Složitost... Je mnohem obtížnější porozumět a vyhodnotit vlastnosti distribuovaných systémů obecně a je složitější je navrhovat, testovat a udržovat. Výkon systému také závisí na rychlosti sítě, nikoli na jednotlivých procesorech. Realokace zdrojů může výrazně změnit rychlost systému.
2. Bezpečnostní... Typicky lze k systému přistupovat z několika různých strojů, zprávy v síti lze monitorovat a zachycovat. Proto je v distribuovaném systému mnohem obtížnější udržet bezpečnost.
3. ovladatelnost... Systém se může skládat z různých typů počítačů, na které lze nainstalovat různé verze operačních systémů. Chyby na jednom počítači se mohou šířit na další počítače nepředvídatelným způsobem.
4. Nepředvídatelnost ... Reakce distribuovaných systémů na některé události je nepředvídatelná a závisí na plné zátěži systému, jeho organizaci a zatížení sítě. Protože se tyto parametry mohou neustále měnit, může se doba odezvy na požadavek od času výrazně lišit.

Z těchto nedostatků je vidět, že při návrhu distribuovaných systémů vzniká řada problémů, se kterými musí vývojáři počítat.

1. Identifikace zdroje ... Prostředky v distribuovaných systémech jsou umístěny na různých počítačích, takže systém pojmenování zdrojů by měl být myšlen tak, aby uživatelé mohli snadno přistupovat a odkazovat na zdroje, které potřebují. Příkladem je systém URL (Uniform Resource Locator), který definuje názvy webových stránek.
2. Sdělení... Univerzální provozuschopnost internetu a efektivní implementace protokolů TCP/IP v Internetu pro většinu distribuovaných systémů jsou příklady nejúčinnějšího způsobu organizace komunikace mezi počítači. V některých případech, kdy je vyžadován speciální výkon nebo spolehlivost, je však možné použít specializované nástroje.
3. Kvalita servisu systému ... Tento parametr odráží výkon, zdraví a spolehlivost. Kvalitu služby ovlivňuje řada faktorů: distribuce procesů, zdrojů, hardwaru a přizpůsobivost systému.
4. Softwarová architektura ... Softwarová architektura popisuje rozložení funkcí systému mezi komponenty systému a také rozložení těchto komponent mezi procesory. Pokud potřebujete udržovat vysoce kvalitní systémové služby, je rozhodující výběr správné architektury.

Výzvou pro návrháře distribuovaných systémů je navrhnout software a hardware tak, aby poskytovaly všechny požadované vlastnosti distribuovaného systému. To vyžaduje znalost výhod a nevýhod různých architektur distribuovaných systémů. Existují tři typy architektur distribuovaných systémů.

1. Architektura klient/server ... V tomto modelu lze systém chápat jako soubor služeb poskytovaných servery klientům. V takových systémech se servery a klienti navzájem výrazně liší.
2. Třívrstvá architektura ... V tomto modelu server neposkytuje služby klientům přímo, ale prostřednictvím serveru obchodní logiky.

O prvních dvou modelech už bylo řečeno nejednou, u třetího se zastavme podrobněji.

1. Architektura distribuovaných objektů ... V tomto případě neexistují žádné rozdíly mezi servery a klienty a systém lze považovat za sadu vzájemně se ovlivňujících objektů, na jejichž umístění ve skutečnosti nezáleží. Neexistuje žádný rozdíl mezi poskytovatelem služeb a jejich uživateli.

Tato architektura je dnes hojně využívána a je také tzv architektura webových služeb. Webová služba je aplikace, která je přístupná přes internet a poskytuje některé služby, jejichž forma je nezávislá na poskytovateli (jelikož se používá univerzální datový formát - XML) a platformě provozu. V současné době existují tři různé technologie, které podporují koncept distribuovaných objektových systémů. Jedná se o technologie EJB, CORBA a DCOM.

Nejprve pár slov o tom, co je XML obecně. XML je obecný datový formát používaný k poskytování webových služeb. Webové služby jsou založeny na otevřených standardech a protokolech: SOAP, UDDI a WSDL.

1. SOAP ( Simple Object Access Protocol, vyvinutý organizací W3C, definuje formát pro požadavky na webové služby. Zprávy mezi webovou službou a jejím uživatelem jsou baleny do tzv. SOAP obálek (někdy také nazývaných XML obálky). Samotná zpráva může obsahovat buď požadavek na provedení nějaké akce, nebo odpověď – výsledek této akce.
2. WSDL (Web Service Description Language).Rozhraní webové služby je popsáno v dokumentech WSDL (a WSDL je podmnožinou XML). Před nasazením služby sestaví vývojář její popis v jazyce WSDL, specifikuje adresu webové služby, podporované protokoly, seznam povolených operací a formáty požadavků a odpovědí.
3. UDDI (Universal Description, Discovery and Integration) - Internet Web Services Search Protocol ( http://www.uddi.org/). Jedná se o obchodní rejstřík, kde poskytovatelé webových služeb registrují služby a vývojáři nacházejí služby, které potřebují zahrnout do svých aplikací.

Z povídání se může zdát, že webové služby jsou nejlepším a nesporným řešením a jedinou otázkou je výběr vývojových nástrojů. Nicméně není. Existuje alternativa k webovým službám, sémantický web, o kterém tvůrce WWW Tim Berners-Lee hovořil před pěti lety.

Pokud je cílem webových služeb usnadnit komunikaci mezi aplikacemi, pak je sémantický web navržen tak, aby řešil mnohem složitější problém – pomocí mechanismů metadat ke zvýšení efektivity hodnoty informací, které lze na webu nalézt. Toho lze dosáhnout opuštěním dokumentově orientovaného přístupu ve prospěch objektově orientovaného.

Bibliografie

1. SomervilleI. Softwarové inženýrství.
2. Dranitsa A. Java vs. .NET. - "Computerra", # 516.
3. Internetové zdroje.