# Modulární a distribuované aplikace

## Abychom si rozuměli

Řekne-li se, že systém Control Web dokáže provozovat modulární a distribuované aplikace, představí si každý něco mírně odlišného. Obě slova — modulární i distribuovaný — totiž mají v obecné řeči celkem široký význam. Control Web a jeho aplikace proto významy upřesňují a chápou je následovně:

- Modulární je aplikace, která sestává z více modulů. Systém Control Web považuje za modul každý jeden aplikační soubor, takže je možné říci, že nejjednodušší aplikace je jednomodulární — taková aplikace se celá nachází v jednom jediném zdrojovém souboru. Většina aplikací systému Control Web je jednomodulární.
- Distribuovaná je vícemodulární aplikace, ve které jednotlivé moduly běží na různých počítačích. Distribuovaná aplikace v systému Control Web běží jako jeden celek, jako jedna velká logická aplikace.

Podle uvedených definic je zřejmé, že distribuovaná aplikace musí být modulární, zatímco aplikace modulární distribuovaná být nemusí. Modulární aplikace tedy může celá pracovat na jednom počítači (v jednom systému Control Web). Taková modulární aplikace pracuje místně — lokálně.

Každý modul modulární aplikace proto může být lokální, pracuje-li na místním počítači, nebo vzdálený, pracuje-li na vzdáleném počítači. Slova "místní" a "vzdálený" jsou navzájem relativní (jejich významy záleží na tom, který počítač si vyberete jako "místní"), a je proto vhodné pro přehlednost stanovit další pravidla (která se budou používat v celé této kapitole):

- Místní modul je modul, který běží na počítači, kde byl spuštěn první modul aplikace.
- Vzdálený modul je modul, který běží na jiném počítači, než kde byl spuštěn první modul aplikace.

Vymezené označení modulů (místní a vzdálený) již dostačuje pro to, abychom dokázali popsat aplikace distribuované i místně-modulární. Ostatně, převážně nás budou zajímat vztahy modulů — a ne aplikací. V dalším textu proto pojmy "distribuovaná aplikace" a "modulární aplikace" budou použity jen v případech, kdy bude důležité jejich přesně rozlišení.

## O modulech a aplikacích

V úvodní sekci bylo naznačeno, že Control Web považuje za moduly jednotlivé aplikační soubory. Každý takový aplikační soubor přitom zůstává samostaným celkem, který je možné ve vývojovém prostředí samostatně upravovovat a překládat. Modulární aplikace proto vzniká logickým spojením samostatně existujících přeložitelných aplikačních souborů — modulů.

Moduly se spojují dovážením. Každý modul může dovážet libovolné jiné moduly a ty zase moduly další, přičemž moduly je možné dovážet i vzájemně — například dva moduly mohou dovážet jeden druhý a druhý zase první (zpětně). Pro dovozy modulů nejsou stanovena žádná omezení, takže vzájemné spojení modulů může vytvořit libovolnou strukturu (obecný graf). Protože neexistuje žádná předem daná struktura modulů (aplikace ji může definovat zcela libovolně), neexistuje také žádný speciální modul, který by mohl být automaticky považován za hlavní.

Aplikace sestávající z více modulů při spouštění postupně překládá jednotlivé zdrojové texty a případně podle zjištěných informací dováží a překládá texty další. Během překladu vzniká struktura modulů, která se vyčítá bezprostředně z jednotlivých modulů samotných. Neexistuje proto žádný speciální soubor, který by strukturu a dovážení jakkoli expliticně definoval.

Uvedená vlastnost automatické výstavby modulární aplikace znamená, že při rozběhu vždy budou spuštěny jen ty moduly, které Control Web během překladu jednotlivých zdrojových textů nalezne. Záleží proto na tom, který modul spustíte jako první. Dovážíte-li do modulu 1 modul 2, spustí při spuštění modulu 1 i modul 2, spustíte-li samostatně modul 2, modul 1 nepoběží, protože na něj překladač v modulu 2 nenajde žádný odkaz. Jednotlivé části modulární aplikace proto můžete ladit i spouštět jako samostatné celky.

Přesto, že není nutné nijak definovat počátek modulární aplikace, existuje v systému Control Web pojem projekt. Naneštěstí se pod tímto pojmem rozumí v systému dvě různé věci: jednak se jako projekt často označuje modulární aplikace (většinou se říká "spuštěný projekt" místo "spuštěná modulární aplikace") a jednak projekt označuje ve vývojovém prostředí uživatelem označený modul, který bude vývojové prostředí považovat za hlavní — tento (druhý) význam popisuje následující oddíl.

### Projekt

Projekt ve vývojovém prostředí označuje modul, který je mezi ostatními moduly uživatelem "povýšen". Vývojové prostředí definovaný projekt používá ve dvou situacích: jednak při spouštění vícemodulární aplikace a jednak při editaci modulů v záložce "Moduly" vývojového prostředí.

Projekt je možné definovat dvojím způsobem. Jednodušší způsob předpokládá, že ve vývojovém protředí máte zavedenu aplikaci, která se má stát projektem — hlavním modulem. V takovém případě projekt definujete pomocí menu "Soubor/Vybrat jako projekt":

Menu Soubor

Druhá varianta spojuje definici projektu s otevřením souboru pomocí příkazu v menu "Soubor/Otevřít projekt...", kdy otevřený soubor bude ve vývojovém prostředí přímo označen za projekt.

Ať již definujete projekt prvním nebo druhým způsobem, vývojové prostředí vždy nově přiřazený projekt oznámí změnou titulku svého okna. Titulek bez definovaného projektu obsahuje pouze jméno aktuálně editovaného souboru:

Titulek bez projektu

titulek vývojového prostředí s definovaným projektem zobrazuje dat více:

Titulek s projektem

Nejprve je zobrazeno jméno projektu, nakonec (v hranatých závorkách) aktuálně zavedený zdrojový soubor. Změníte-li projekt, upraví se první část titulku, otevřete-li jiný aplikační soubor, změní se konec titulku. Vzhledem k tomu, že definice projektu je pouze logická, není nijak omezena jakákoli práce s vývojovým prostředím. Otevírané soubory s projektem vůbec nemusejí souviset, a přesto je budete moci normálně vyvíjet.

Definovaný projekt pomáhá zrychlit rozběh modulární aplikace, neboť vývojové prostředí nabízí v nástrojové liště a menu příkaz "Aplikace/Spustit projekt":

Spuštění projektu

Spuštění projektu (na rozdíl od spuštění modulu) nejprve vnitřně zavede soubor projektu a teprve poté aplikaci spustí. Bez ohledu na právě zavedný zdrojový text proto spouštění projektu začne vždy modulem projektu. Běžné spouštění jednoho modulu nebere na nastavení projektu ohled a spustí vždy aplikaci aktuálně zavedenou do vývojového prostředí. Samozřejmě, obsahuje-li zdrojový text při spouštění modulu dovoz nějakého jiného modulu, spustí se aplikace celá, se všemi moduly. Rozdíl mezi spuštěním projektu a spuštěním modulu je tak redukován pouze na zavádění (případně nezavádění) modulu projektu.

Spuštění modulární aplikace se od spuštění jednoduché aplikace mírně odlišuje. Hlavní příčina odlišnosti spočívá v nutnosti zavádět a překládat postupně různé zdrojové texty. V jednom okamžiku je tak v systému přítomen — zaveden vždy jen jeden zdrojový text. Výměna souborů však může přinést určité problémy, které Control Web ošetřuje různými prostředky.

Především, běžně nastává situace, kdy soubor v editoru není uložen. Obsah aplikace proto existuje ve dvou podobách — nové, která existuje v textovém editoru a staré, která existuje v souboru uloženém na disku. Jak již víme, systém Control Web při spouštění soubory zavádí a překládá postupně. Neuložený soubor v editoru znemožňuje zavedení jiného souboru, nehledě na fakt, že na disku existuje stejný modul v jiném — starším provedení. Vývojové prostředí proto při spouštění modulární aplikace vyžaduje, aby byl editovaný soubor uložen, a otevírá proto případně během spouštění následující dialogové okno:

Soubor není uložen

Druhý (skrytý) problém se soubory vznikne v okamžiku, kdy během spouštění dojde k vygenerování některého z modulů (dojde k překlopení z grafického do textového editoru). Nově vygenerovaný text se může lišit od textu obsaženého v aplikačním souboru, neboť aplikace po generování v určitých případech může změnit (mírně) podobu (o generování hovoří kapitola Integrované vývojové prostředí. Ačkoli jsou změny způsobené generováním drobné, přesto vzniknou dvě podoby jednoho modulu — v souboru a v editoru. Dvojí existence jednoho modulu může způsobit kolize, a vývojové prostředí proto aplikaci nespustí (i přesto, že by se pravděpodobně nic nestalo) a informuje uživatele následujícím oknem:

Obsah souboru na disku a editoru se liší

Poslední operací, kterou je občas třeba provést, je zrušení projektu. I když zní název nebezpečně, nejedná se o nic jiného, než o zrušení "povýšení" prvního modulu projektu (použitím povelu se tedy nic nesmaže). Vybraný modul přestane být vyjímečný a vývojové prostředí změní svůj titulek.

### Dostupnost vzdálených objektů

Modulární aplikace v běžícím stavu zahrnuje potenciálně velké možství modulů, které navzájem komunikují — používají svá data nebo aktivují své přístroje. Všechny moduly jsou dostupné a vazby mezi nimi (které byly určeny během vývoje) jsou známé a vyřešené. Požaduje-li modul a datový element modulu b, může se spolehnout na to, že modul b běží. Přečtení elementu proto není žádný problém.

Modulární aplikace (stejně jako každá jiná) se však před nasazením musí vyvinout a sestavit. Již bylo řečeno, že vícemodulární aplikace vzniká zavedením logických vazeb mezi moduly, a že tento způsob nebrání samostatné editaci (vývoji) jednotlivých modulů. Avšak i vyvíjený modul již definuje dovozy jiných modulů, stejně jako již používá odkazy na objekty těchto modulů. Cizí moduly však během vývoje neběží a jsou tudíž nedostupné.

O všech objektech, které se mají nacházet v cizích modulech, proto nelze nic zjistit. Ani datových elementů ani přístrojů se není možné zeptat, jakého jsou typu nebo jaké mají k dispozici nativní procedury. Vyvíjený modul se proto musí spokojit pouze s tím, co do něj zapíšete — překladač je schopen kontrolovat pouze formální pochybení v zápisu zdrojového textu. Během vývoje je tudíž klidně možné používat logickou proměnnou (že je proměnná logická ovšem překladač nemůže zjistit) na výstupu řetězcového přístroje. Stejně tak je možné vzdáleným přístrojům zapisovat volání jakýchkoli (i nesmyslných) procedur.

Všechny tyto během vývoje nedefinované vazby se začnou ustavovat až při spuštění aplikace. Proto je celkem běžné, že první spuštění modulární aplikace odhalí velké množství doposud nezjistitelných chyb.

Vývoj každé vícemodulární aplikace proto bude kroužit ve smyčce o dvou krocích — nejprve je vždy třeba navrhnout a podle návrhu vytvořit (krok 1) přeložitelné části modulů, které se poté postupně spouštějí (krok 2), přičemž postupně dochází k odhalování nesrovnalostí a jejich nápravě. Tato komplikace při vývoji vícemodulární aplikace se nedá nijak obejít. Modulární aplikaci je proto nutné promyslet při návrhu do větší hloubky než jednoduchou (jednomodulární) aplikaci, aby se co nejvíce zmenšil počet vazeb, které se jinak budou muset odhalovat až při (poměrně zdlouhavém) postupném spouštění.

## Místní moduly

### Proč použít místní moduly

Může se zdát, že místní modul nepředstavuje nic jiného, než trochu složitější cestu k datům, která mohla být přímo dostupná v rámci jednoho kusu aplikace. Jeden velký aplikační soubor sice rozdělíte na menší moduly, ale ty nakonec pracují zase pospolu bez přílišného oddělení v jednom systému Control Web. Proč tedy místní modulární aplikace vůbec používat?

- Modulární aplikace zavádějí do projektu pořádek. Jednak nutí programátora, aby se zamyslel nad umístěním dat a přístrojů v jednotlivých modulech (a logicky si je oddělil), a jednak zjednodušují orientaci ve velkých aplikacích. Například je výhodné do samostatných modulů rozmístit jednotlivé logické technologické celky, neboť je potom okamžitě jasné, čeho se modul týká, a co obsahuje. Navíc, menší moduly je možné snadněji a rychleji udržovat a upravovat.
- V modulárních aplikacích můžete velmi snadno oddělit funkční část od části servisní nebo ladicí. Například, jeden modul může zahrnovat pouze ladicí, diagnostické a simulační přístroje. Během vývoje bude tento modul součástí aplikace (bude v některém z výkonných funkčních modulů dovezen) a při dokončení úlohy jej vyřadíte.
- Modulární aplikace mohou pracovat efektivněji a mohou spotřebovat méně systémových prostředků. Uvažme jednomodulární aplikaci, ve které bude deset archiverů pracujících v dlouhých intervalech (minuty či hodiny) a deset grafů pracujících velmi rychle (třeba stokrát za sekundu).

Jádro aplikace bude podle požadavků všechny přístroje časovat, takže stokrát za sekundu aktivuje grafy a mezi tím s delšími rozestupy také archivery. Ale, při výpočtu každého nového časového kroku jádro musí počítat se všemi přístroji, tedy i s archivery. Jádro bude v každém svém časovém kroku počítat data grafů i archiverů. Ve většině případů (více než 99,9 %) bude výpočet pro archivery nadbytečný. Vyčlení-li se archivery do samostatného modulu (grafy zůstanou v modulu původním), budou výpočty časových kroků probíhat mnohem efektivněji. Rychlý modul bude časovat rychle, ale pouze grafy, a pomalý modul bude obsluhovat jen pomalé archivery. Zvýšení efektivity tedy spočívá v oddělení skupin přístrojů s řádovými rozdíly v periodách časování (o časování podrobně pojednává kapitola Časování aplikací reálného času.

Místní moduly jsou uvnitř systému svázány velmi úzce a aplikace s jejich využitím pracuje stejně rychle (téměř stejně rychle, s neměřitelným zpomalením) jako aplikace jednomodulární. Je proto celkem lhostejné, navrhnete-li aplikaci jako jeden velký modul, nebo jako více menších spolupracujících modulů.

### Dovoz místního modulu a jeho objektů

Do jakéhokoli modulu dovezete jiný modul následující definicí sekce import:

    import
      local = 'mod2';
    end_import;
    ...

Řetezec mod2 představuje současně jméno modulu i jméno souboru s kódem modulu. Není možné nazvat modul jinak, než jménem jeho souboru.

V případě ukázky bude do stávající aplikace dovezen místní modul mod2. Od tohoto okamžiku je modul mod2 v celém zdrojovém textu viditelný a dostupný pro všechny způsoby použití. V zápisu dovozu je důležité především klíčové slovo local, které určuje, že bude modul dovezen místně.

Povšimněte si, že jméno modulu neobsahuje ani cestu, ani příponu souboru. Takový zápis je nejjednodušší, a zároveň nejvíce automatický, protože je plně obsluhován systémem:

- Nejprve systém hledá pomocí přesměrování soubor, ke kterému doplní příponu stejnou, jakou má první modul projektu.
- Nebyl-li soubor nalezen, pokusí se systém použít příponu, která odpovídá verzi systému — ve vývojové verzi tedy příponu 'cw' a v Control Web Runtime příponu 'cwx'.
- Nebyl-li soubor stále nalezen, pokusí se systém použít příponu opačnou — ve vývojové verzi příponu 'cwx' a v Control Web Runtime příponu 'cw'.

Uvedete-li do jména modulu cestu nebo příponu, bude ji samozřejmě systém plně respektovat, avšak nebude možné použít celého výše posaného mechanizmu — uvedete-li cestu, nebude použito přesměrování, uvedete-li příponu, nebudou se přípony automaticky doplňovat.

S vyhledávání cest k souborům modulů úzce souvisí vyhledávání jakýchkoli datových souborů, které aplikace používá. Každý jednotlivý modul zůstává samostatnou jednotkou a používá proto přirozeně veškerá svá nastavení, mezi než patří i definice přesměrování souborů pomocí aplikační sekce directories. Teoreticky je proto možné, aby každý modul aplikace hledal své datové soubory (a moduly které dováží) v naprosto rozdílných adresářích. Prakticky to však nelze doporučit.

Dokonce je možné, že během spouštění modulů s různými přesměrováními nastane situace, kdy některý modul požaduje dovoz modulu, který již byl jednou dovezen jiným modulem z jiného adresáře. Vznikne situace, kdy se jeden z modulů snaží použít potenciálně naprosto nevhodný soubor. Celou situaci demonstruje příklad (ve formě postupu):

1. adresář 'C:\Program Files\Control Web\Aplikace' obsahuje soubor 'm1.cw'. Zdrojový text v tomto souboru obsahuje sekci directories, která definuje, že se soubory '*.cw' mají hledat v adresáři 'C:\Program Files\Control Web\Prog'.
2. adresář 'C:\Program Files\Control Web\Prog' obsahuje jiný soubor 'm1.cw' a navíc soubor 'm2.cw'. Oba tyto moduly mají sekci directories definovánu, ale sekce pro soubory '*.cw' nedefinuje žádné pravidlo.
3. Oba moduly 'm1' dovážejí modul 'm2' zápisem local = 'm2';, modul 'm2' dováží pomocí local = 'm1'; modul 'm1'. Moduly se tedy dovážejí navzájem.
4. Do vývojového prostředí se zavede modul 'Aplikace\m1.cw' a aplikace se spustí.
5. Modul 'm1' dováží modul 'm2'. 'm1' podle svého přesměrování zjistí, že 'm2' najde v adresáři 'Prog' a zavede jej.
6. Překladač zjistí, že modul 'm2' dováží modul 'm1'. Podle přesměrování modulu 'm2' se zjístí, že modul 'm1' je dostupný také v adresáři 'Prog'. Systém se proto pokusí zavést modul 'Prog\m1'.
7. Vznikne chyba, kdy systém obsahuje již existující (a zaregistrovaný) modul 'Aplikace\m1' (tento modul byl spuštěn), a současně modul 'm2' požaduje modul 'Prog\m1'.

Systém Control Web na takovou situaci reaguje okamžitým zastavením rozběhu a otevřením následujícího chybového okna:

Kolize cest souborů modulů

Je nutné říci, že popsaný mechanizmus dovozu více různých modulů stejného jména v principu nijak nevadí, a bylo by docela dobře možné takovou aplikaci bez potíží provozovat. Nicméně, sami asi vidíte, že pomíchání různých modulů nejčastěji vznikne pouhým přehlédnutím — přejmenováním souboru nebo nedostatečným smazáním souboru jiného. Je proto vhodné, aby systém takové situace kontroloval a rozběh takové aplikace uměle znemožnil. Pokud se totiž moduly pomíchají většinou kvůli přehlédnutí, je hlášení chyby velmi důležitý způsob, jak předejít závažným potížím v běhu aplikace (klidně by se mohlo stát, že by aplikace běžela zcela špatně s jedním zapomenutým modulem starým několik měsíců).

Velmi podobná situace, kdy může dojít ke zmatení souborů, vznikne při současném výskytu souborů 'cw' a 'cwx' jednoho modulu. Situaci opět demonstruje krátký postup:

1. adresář 'C:\Program Files\Control Web\Prog' obsahuje tři soubory 'm1.cw', 'm1.cwx' a 'm2.cwx'. Všechny tyto moduly mají sekci directories definovánu, ale ani jedna ze sekcí nedefinuje žádné pravidlo pro soubory '*.cw' ani '*.cwx'.
2. Oba moduly 'm1.cw' i 'm1.cwx' dovážejí modul 'm2.cwx' zápisem local = 'm2.cwx';, modul 'm2.cwx' dováží pomocí local = 'm1.cw'; modul 'm1'. Moduly se tedy dovážejí navzájem. Povšimněte si, že dovozy mají definovánu příponu, takže systém nic automaticky nedoplňuje a řídí se přímo zapsanými údaji.
3. Do vývojového prostředí se zavede modul 'Aplikace\m1.cwx' a aplikace se automaticky spustí.
4. Modul 'm1.cwx' dováží modul 'm2.cwx'. 'm2.cwx' je okamžitě nalezen a zaveden.
5. Překladač že modul 'm2.cwx' dováží modul 'm1.cw'. 'm1.cw' je také okamžitě nalezen.
6. Při zavedení modul 'm1.cw' vznikne chyba, kdy systém obsahuje již existující (a zaregistrovaný) modul 'Prog\m1.cwx' (tento modul byl spuštěn), a současně modul 'm2.cwx' požaduje modul 'Prog\m1.cw'.

Opět vznikla kolize, tentokrát ovšem na úrovni přípon souborů. I v tomto případě se jedná o formální chybu, která nejspíše vznikla z nepozornosti, a Control Web proto opět rozběh aplikace hlášením stejné chyby ukončí.

Jak tedy postupovat, aby k podobným komplikovaným chybám při dovozech nedocházelo? S vysokou pravděpodobností vždy uspějete, pokud se budete držet následujích dvou doporučení:

- Pečlivě plánujte rozmístění jednotlivých aplikací a jejich datových souborů. Nejbezpečnější strategie spočívá v umístění všech modulů a jejich datových souborů do jediného adresáře. Jednotlivé moduly potom mají sekci directories definovánu, leč nenaplněnu. Jiná možná strategie (již ale ne tak bezpečná) spočívá v použití jedné jediné sekce directories umístěné jen v hlavním modulu (to je ten, kterým se aplikace spouští). Ostatní moduly nesmějí mít sekci directories definovánu. V takovém případě všechny moduly (kromě hlavního) převezmou přesměrování hlavního modulu a řídí se jím.
- Nedefinujte u jmen modulů přípony souborů. Automatický mechanizmus přiřazení přípon pracuje spolehlivě, a vy se vyhnete potížím s moduly různých verzí ('cw' nebo 'cwx') při přechodu z vývojové do runtime verze.

O přesměrování i o vyhledávání souborů v modulárních aplikacích se můžete také dočíst v kapitole Soubory systému Control Web.

Vlastní použití objektů cizího modulu je velmi jednoduché. Jméno modulu se používá jako prefix, který se zapisuje před jméno objektu z cizího modulu. Například:

    a = mod2.a + a;
    ...
    output = mod2.channel_205;
    ...
    send mod2.program_SwitchPanels;
    ...
    mod2.program_SwitchPanels.SetActivePanel( 4 );

Ukázka zobrazuje všechny možnosti použití objektů cizího modulu mod2:

- čtení proměnné nebo kanálu (mod2.a)
- zápis proměnné nebo výstupního kanálu (mod2.channel_205)
- poslání zprávy přístroji (send mod2.program_SwitchPanels)
- volání procedury přístroje (mod2.program_SwitchPanels.SetActivePanel)

Povšimněte si, že zápis přístupu na externí objekty ekvivalentně odpovídá zápisu přístupu na objekty lokální — například poslední případ: volání procedury sestává z částí zcela shodných s lokálním voláním — modul.jméno_přístroje.jméno_procedury( seznam_parametrů ).

Seznam možností, jak použít objekt cizího modulu, je úplný, z čehož vyplývá:

- Není možné použít konstanty cizího modulu.
- Není možné přistupovat k atributům kanálů cizího modulu.
- Je možné použít systémových proměnných cizího modulu.
- Je možné volat systémové nativní procedury cizího modulu.

### Synchronizace modulů

Místní moduly spuštěné v rámci jednoho projektu (v rámci jedné vícemodulární aplikace) sdílejí výkonný aplikační tok. Zpracování veškerých uživatelských událostí, kreslení na obrazovku i běh všech přístrojů ze všech modulů se odehrávají v tomto výkonném toku (o běhu aplikace v různých prováděcích tocích jste se mohli dočíst v kapitole Časování aplikací reálného času. Každý modul nicméně spouští svůj vlastní časovací tok, který pohání přístroje jemu patřící.

Jednotlivé moduly mohou realizovat nejrůznější činnosti a mohou být zcela libovolným způsobem organizovány. V některých modulech mohou být přístroje současně s ovladači a kanály, v modulech jiných najdete třeba jen kanály nebo jen přístroje. Pro běh vícemodulární aplikace je nutné, aby veškeré vnější zásahy a požadavky z jiných modulů vyvolávaly stejné akce jako požadavky lokální.

K vysvětlení této myšlenky poslouží příklad: asi již víte, že v aplikacích reálného času komunikace dat kanálů řídí jádro, které ovšem informace o měřených kanálech zjišťuje z přístrojů vykonávajících vlastní činnost aplikace. Nejsou-li v modulu žádné přístroje, aplikace nevykonává žádnou činnost a kanály není třeba komunikovat.

Kdybyste však sestavili modulární aplikaci, zjistili byste, že modul, ačkoli bez přístrojů, musí pracovat jako by je měl. V modulárních aplikacích je totiž běžné, že jeden komunikující modul pohánějí požadavky modulů jiných. Uvnitř systému Control Web proto v běžící modulární aplikaci existuje jakýsi klient-server systém, který zaručuje správné komunikace vzdálených kanálů.

Komunikující modul (jádro) je serverem, který vyřizuje požadavky modulů (jader, přesněji přístrojů) klientských. Základní mechanizmus časování — zjišťování kanálů, jež se mají měřit — zůstává nezměněn, požadavky na měření se pouze přesměrovávají do cizího modulu. Cizí modul nejprve shromáždí požadavky, posléze zahájí komunikaci a nakonec po doměření dat žádající modul (který na výsledek čeká) o výsledku informuje — moduly se navzájem synchronizují. Cizí jádro přitom pracuje zcela normálním způsobem — jako by běželo samostatně. Do všech komunikací požadovaných z cizích modulů se tudíž zcela normálně promítají napříkad i komunikační prodlevy.

Klientský modul je však přeci jen cizí modul, a nemá prostředky na detailní kontrolu komunikace v cizím modulu. Může se proto stát, že serverový modul (ze své vlastní vůle) jednorázově komunikaci prodlouží (například kvůli spolehlivému zajištění měření několika důležitých kanálů). Klientský modul s něčím takovým nemusí počítat. Návrh vícemodulární aplikace sice musí zvážit a promyslet i takové varianty, ale přeci jen — vždy se může objevit něco nečekaného, něco, s čím se nedalo počítat. Každý klientský modul proto obsahuje bezpečnostní prodlevu, která zaručuje, že se na serverový modul nebude čekat na synchronizaci déle.

Prodleva sychronizace mezi jednotlivými moduly se nastavuje pomocí parametru remote_sync_timeout sekce settings aplikace. Její předdefinovaná hodnota je 5 sekund. Synchronizace požadavků měření může být v určitých případech nadbytečná. Tehdy klientský modul data kanálů ze serverového modulu přímo vyčte, aniž by jakkoli čekal na doměření — bude tedy vždy číst hodnotu z kroku jádra, v němž byl kanál naposledy změřen. Používání nebo nepoužívání sychronizace měření záleží především na charakteru kanálů a komunikací v serverovém modulu — například klientský modul, který bude číst kanál ze serverového modulu jednou za hodinu bez synchronizace měření, získá vždy hodnotu z předchozího měření — hodnotu hodinu starou; pokud bude měření synchronizováno, získá vždy hodnotu aktuální. Obecně je možné říci, že kanály, které jsou dostatečně rychle měřeny přímo serverovým modulem samotným, mají hodnotu stále aktuální, zatímco kanály, které jsou měřeny řídce (a pouze z klientských modulů) nikoli.

Čekání na mezimodulovou sychronizaci měření kanálů řídí parametr remote_sync sekce settings aplikace. Jeho přednastavená hodnota je true, což znamená, že se moduly při měření synchronizují.

Oba uvedené parametry (remote_sync i remote_sync_timeout) je možné nastavit také v záložce "Systém" "Datových inspektorů" vývojového prostředí.

## Vzdálené moduly

### Distribuovaná aplikace

Pokud jednotlivé moduly modulární aplikace pracují na různých počítačích, hovoří se o aplikaci distribuované. Distribuce aplikace je zajištěna pomocí současného běhu více systémů Control Web a vzájemné výměny dat (komunikace) mezi těmito systémy. Každý jeden systém Control Web pracuje samostatně na jednom počítači (běžících systémů Control Web je stejný počet jako počítačů, na nichž systémy běží) a provozuje alespoň jeden modul distribuované aplikace. Platí přitom pravidlo, že všechny moduly jedné aplikace budou pracovat v jednom systému Control Web. Výměna dat — komunikace v distribuovaných aplikacích probíhá pomocí síťového propojení jednotlivých počítačů.

Stejně jako v případě lokálních aplikací je i v distribuovaných aplikacích možné vytvořit libovolnou strukturu modulů, které se navzájem mohou dovážet zcela neomezeně, cyklicky i navzájem. Tato volnost umožňuje navrhnout zcela libovolnou distribuovanou aplikaci. Některé varianty použití se přímo nabízejí, jako například: jeden modul může obstarávat archivace, tvorbu protokolů, vizualizaci a provoz http serveru (přístroj httpd) a druhý modul běžící na jiném počítači může sbírat data, řídit technologii a současně předzpracovávat data pro první modul. Takové rozdělení je velmi přirozené a může být také velmi účinné.

Dovozem cizího modulu se automaticky modul stává závislým na dovezeném modulu. Tato závislost je velmi pevná — modul přistupuje na proměnné a kanály cizího modulu, případně volá jeho procedury a vyčítá výsledky těchto volání. Jak proměnné nebo kanály, tak výsledky volání procedur mohou být pro dovážející modul kritické a modul bez jejich správné funkce vůbec nemusí být schopen pracovat. Dojde-li proto k přerušení toku dat a příkazů mezi moduly, musí závislý modul ukončit svou činnost — nelze totiž nijak rozhodnout, jestli "zrovna tento kanál nevadí" nebo jestli výpadek nic neovlivní. O přerušení (a způsobu přerušení) komunikace nebývá předem nic známo a na data, která jsou případně ještě k dispozici, se proto vůbec nelze spolehnout.

Jinými slovy, závislý modul potřebuje se svými dovezenými moduly neustále komunikovat. Pokud se komunikace přeruší, nebo pokud dovážený modul přestane pracovat, musí se ukončit i všechny závislé moduly.

Přímým důsledkem tohoto faktu je skutečnost, že distribuovaná aplikace pracuje jako jeden celek, jehož každá jednotlivá část musí běžet. Dojde-li k poruše některého modulu, musí být ukončena celá distribuovaná aplikace, neboť rozsah poškození způsobený výpadkem jednoho modulu není zjistitelný. Celá situace je velmi podobná jednoduché jednomodulární aplikaci — kdyby přestaly v jednoduché aplikaci (hypoteticky) pracovat například archivery, ztratila by smysl celá aplikace, protože by jedna její velká část nefungovala. Přestane-li v distribuované aplikaci pracovat nějaký modul, ztratí rázem smysl i všechny ostatní moduly.

Podobnost mezi příměrem jednomodulární a distribuované aplikace vyvstane velmi zřetelně, vytvoří-li se myšlenkovým experimentem (absurdní) extrém — představte si, že z jedné aplikace vydělíte po jednom všechny přístroje do samostatných modulů, které rozběhnete na samostatných počítačích. Aplikace (nyní distribuovaná) poběží stejně, přičemž jednotlivé její přístroje na sobě budou záviset stejně jako v jednoduché aplikaci. Porucha jednoho z přístrojů (například dělení nulou) by zastavila jednomodulární aplikaci a musí proto zastavit i aplikaci distribuovanou. Distribuovaná aplikace totiž není nic jiného než normální aplikace, ve které jsou zviditelněny vnitřní vazby.

Důsledky silných vazeb mezi moduly distribuované aplikace jsou v souhrnu následující:

- Distribuovaná aplikace musí vždy běžet jako celek. Všechny její moduly musejí pracovat.
- Dojde-li k zastavení některého z modulů, musí se ukončit i všechny moduly závislé, aby se vyloučila možnost běhu s naprosto špatnými daty.
- Dva moduly distribuované aplikace nikdy nemohou vytvořit systém horké zálohy. Oba moduly se totiž (i když třeba jen minimálně) musejí navzájem informovat o stavu technologie a řízení — musejí tedy alespoň jednou jeden druhého dovézt. Tím ale vznikne vazba — závislost, která v případě výpadku jednoho ze systémů automaticky ukončí i systém druhý. Systém s horkou zálohou tedy není distribuovaná aplikace. (Jak se takový systém dá vyrobit se můžete dočíst v sekci Spolupracující moduly.)
- Je zbytečné používat distribuovanou aplikaci v situaci, kdy předem víte, že data, která budou mezi moduly proudit, nemohou způsobit žádnou vážnou chybu — v takovém případě je škoda k sobě moduly pevně vázat.

Pokud se nyní na distribuovanou aplikaci podíváte jako na celek, zjistíte, že je velmi podobná lokální vícemodulární aplikaci. V obou případech musí běžet všechny moduly, v obou případech se mezi moduly vyměňují data a v obou případech nedostupnost dat v některém z modulů způsobí ukončení celé aplikace. Distribuované aplikace se proto programují velmi podobně jako lokální aplikace a nabízejí také velmi podobnou škálu vlastností a vzorců chování. Bylo by možné říci, že distribuovaná aplikace vznikne z lokální modulární aplikace rozesetím modulů po několika počítačích s tím, že veškeré dosud skryté vnitřní vazby mezi moduly (výměny dat nebo synchronizace) opustí jeden počítač a rozprostřou se po celé počítačové síti. Přitom jednoduchost použití modulů zůstává při přechodu k distribuovaným aplikacím stejná — všechny síťové komunikace a nastavení zůstavají skryty hluboko v systému — jsou pro uživatele transparentní.

Distribuované aplikace systému Control Web používají pro výměnu informací sítí s protokoly TCP/IP. O vlastnostech těchto protokolů se můžete dočíst v kapitole Co je to TCP/IP, zde jsou uvedena pouze nejdůležitější fakta:

- TCP/IP jsou standardní protokoly Internetu. Jejich použití tak umožňuje provozování distribuované aplikace celosvětového rozsahu.
- TCP/IP jsou protokoly léty ověřené, jejich vznik se datuje do poloviny šedesátých let.
- TCP/IP jsou protokoly bezpečné, neboť při jejich návrhu bylo hlavním požadavkem zajištění spojení při takřka jakýchkoli poruchách struktury sítě.

Control Web nad těmito protokoly definuje svou vrstvu (aplikační protokol) s následujícími vlastnostmi:

- Protokol je co nejvíce přizpůsoben způsobu vnitřních komunikací objektů aplikací.
- Protokol používá stejné datové jednotky jako aplikace sama. Výměny dat uvnitř aplikace a mimo aplikaci (přes síť) se tedy nijak neliší.
- Protokol je (téměř) absolutně bezpečný, neboť veškerý datový tok je průběžně šifrován. Použité šifrovací mechanizmy jsou kryptograficky silné a jsou navíc zodolněny použitím klíčů delších, než jaké jsou doporučeny pro maximální zajištění.

### Control Web Daemon

Běžící distribuovaná aplikace představuje několik samostatně běžících systémů Control Web, které se při rozběhu aplikace musejí automaticky spustit (nedá se očekávat, že by je tam někdo připravil). Jak ovšem na dálku přes síť spustit Control Web a v něm ještě navíc požadovanou aplikaci?

Velmi jednoduše. Součástí každé instalace systému Control Web je malý program, který se standardně po instalaci zařadí mezi programy spouštěné při startu operačního systému (při každém startu počítače se tedy automaticky zavede). Jmenuje se Control Web Daemon a slouží coby prostředník při navazování síťových spojení distribuovaných aplikací.

Běh Control Web Daemon signalizuje ikonou zařazenou do TaskBaru (lišta s úlohami):

Ikona Control Web Daemon

Pokud na tuto ikonu kliknete pravým tlačítkem myši, objeví se menu, ze kterého je mimo jiné možné Control Web Daemon ukončit:

Menu Control Web Daemon

Control Web Daemon dokáže spustit i zastavit Control Web. Navíc průběžně shromažďuje informace o modulech, které ve všech lokálních systémech Control Web pracují. Uvedené informace jsou důležité, neboť bez jejich znalosti by nemohly cizí systémy Control Web rozhodnout, jestli je spojení možné navázat nebo nikoli.

Asi nejdůležitější je schopnost Control Web Daemon spouštět systémy Control Web. Control Web Daemon ctí produkt, jehož je součástí, a v případě potřeby vždy spustí verzi Control Web, která odpovídá jemu samému. Příklad: na jednom počítači můžete mít nainstalovány dvě licence — jednu verzi vývojovou a druhou runtime. Spustíte-li Control Web Daemon z verze vývojové, bude při přijetí požadavku na spuštění spuštěna verze vývojová, spustíte-li Control Web Daemon z verze runtime, bude spuštěna verze runtime. Provozujete-li proto dvě licence uvedeným způsobem, musíte vždy v případě potřeby zkontrolovat, jestli je spuštěn správný Control Web Daemon.

Control Web Daemon je během startu a zastavení aplikace používán jako server. To znamená, že jednotlivé systémy Control Web, které si přejí na počítači spustit aplikaci, posílají požadavky do Control Web Daemon, ten provede potřebné akce a žádajícímu systému posléze odpoví. Také to znamená, že Control Web Daemon musí běžet na všech počítačích, kam se někdo připojuje. Toto pravidlo je možné definovat také jinak — Control Web Daemon musí běžet na všech počítačích, které jsou uvedeny v jakémkoli modulu distribuované aplikaci v sekci import.

Control Web Daemon je prvním programem, který na cizím počítači Control Web hledá. Pokud na něm Control Web Daemon neběží, Control Web nic nenajde, a distribuovaná aplikace nebude moci pracovat. Control Web Daemon je tedy základní podmínkou provozu distribuované aplikace. Na druhé straně, pokud provozujete výhradně jednomodulární nebo lokální modulární aplikace, nepotřebujete Control Web Daemon vůbec a můžete jej s klidným svědomím zastavit i vyřadit ze seznamu automaticky startovaných programů.

### Způsoby spojování modulů

Lokální modulární aplikace vystačily s jedním způsobem dovozu modulů — pomocí klíčového slova local v sekci import. Místní modul byl tímto způsobem dovezen pevně — bez možnosti případného odpojení a opětovného napojení.

V distribuovaný aplikacích se moduly mohou dovážet dvěma způsoby. První způsob — remote — odpovídá analogicky lokálnímu dovozu pomocí local. Dovoz remote vytvoří pevnou vazbu mezi dováženým a dovážejícím modulem. Automaticky také vznikne závislost dovážejícího modul na dováženém. Pomocí dovozů remote vytvoříte distribuovanou aplikaci se všemi jejími výhodami a nevýhodami, tak jak byly popsány v předcházejím oddíle.

Druhý způsob, jak v distribuované aplikaci dovézt cizí modul, je dočasné napojení na běžící aplikaci (dovoz pomocí klíčového slova attach). Modul, který dováží některý z již běžících modulů aplikace tímto způsobem, může být kdykoli později zastaven a odpojen aniž by došlo k zastavení (nebo jinému ovlivnění) dováženého modulu. Dovozy attach použijete nejspíše v případech, kdy potřebujete na chvíli nahlédnout na dlouhodobě běžící aplikaci. Můžete tak vytvořit například aplikaci se dvěma moduly — jeden z nich nepřetržitě řídí a archivuje (a nic nevizualizuje), a druhý z nich jen vizualizuje. Druhý modul je však je spouštěn (a připojován pomocí attach) jen občas, v situacích kdy se na aplikaci chcete podívat. Je přitom lhostejné, z jakého počítače (uvnitř podnikové sítě, nebo v Internetu) se připojíte.

Oba způsoby vzdáleného připojení mají další následující vlastnosti:

- remote — chování takto dovezených modulů, stejně jako způsob jejich řízení systémem Control Web, je velmi blízký chování modulů dovezených jako local. Platí stejná pravidla pro spouštění i zastavování — všechny moduly projektu musejí být v okamžiku startu aplikace dostupné a všechny budou spuštěny. Při zastavení projektu budou všechny moduly zastaveny.

- První požadavek na spuštění vzdáleného modulu způsobí na vzdáleném (cizím) počítači nejprve spuštění nové instance systému Control Web, který teprve spustí požadovaný modul. Další moduly, které se budou v této aplikaci na daném počítači spouštět, použijí již existující rozběhnutý Control Web a budou se přidávat k doposud běžícím modulům. Nastane tedy podobná situace jako v případě modulů dovezených pomocí local — jeden Control Web bude provozovat více modulů, které mohly být různě požadovány z různých počítačů. Spolu s těmito moduly poběží i všechn moduly, které byly dovezeny místně v sekcích import spuštěných modulů.
- Pokud při startu modulu dovezeného pomocí remote nastane chyba překladu, bude zastaven rozběh celého projektu, a chyba bude hlášena pouze na počítači, který spustil první modul aplikace. Projekt bude úspěšně spuštěn, pokud budou úspěšně nalezeny všechny jeho moduly (dovezené jako local i remote) a podaří-li se všechny tyto moduly úspěšně rozběhnout.
- Distribuovanou aplikaci je možné zastavit z kteréhokoli místa (z každého počítače, který provozuje některý z modulů aplikace), přičemž informace o zastavení se automaticky rozšíří do všech ostatních modulů. Systémy Control Web, které byly při rozběhu aplikace automaticky spuštěny, budou ukončeny, a jako jediný běžící Control Web po zastavení aplikace zůstane ten, který spustil první modul.

- attach — dovoz modulů tímto způsobem umožňuje nezávislé připojení na běžící aplikaci

- Od dovozu remote se dovoz attach liší tím, že dovážený modul ani nerozbíhá ani nezastavuje. Při dovozu pomocí attach je pouze ověřeno, jestli na požadovaném počítači běží nějaký systém Control Web a jestli v tomto systému běží požadovaný dovážený modul.
- Pokud je běžící modul nalezen, je dále ověřeno, jestli modul attach připojení povoluje a jestli má připojovaný uživatel dostatečná práva. Pokud jsou tyto podmínky splněny, spojení se naváže a dovážející modul se rozběhne. Připojení pomocí attach modul cizím modulům povoluje parametrem allow_attach sekce settings aplikace. Standardně je hodnota parametru false, a potřebujete-li proto modul pro attach připojení zpřístupnit, musíte parametr nastavit na hodnotu true. Práva připojovaného uživatele se kontrolují jen v případě, definuje-li modul v sekci settings parametr attach_level. Hodnota parametru určuje jaká nejnižší práva musí mít uživatel, aby bylo jeho připojení uskutečněno. Modul, který se pomocí attach připojuje k modulu s definovaným parametrem attach_level, otevírá před navázáním spojení dialogové okno, pomocí něhož je možné se přihlásit. Použijete-li parametr attach_level, musíte v aplikaci povolit systém uživatelů (o uživatelích, heslech a přístupových právech se dočtete v kapitole Systém kontroly uživatelských práv.
- Zastavení modulu, který je pomocí attach připojen na cizí moduly, pouze ukončí spojení se vzdáleným počítačem a nezpůsobí tak ukončení běhu vzdáleného systému.
- Naopak, dovážející modul se v okamžiku připojení na běžící modul stává závislým a musí být ukončen, dojde-li k zastavení dovezeného modulu. Vazba pomocí attach je stejně silná jako vazba remote.
- Připojování modulu pomocí attach má jedno omezení — modulu dovezenému jako attach není možné volat procedury a posílat zprávy přístrojům pomocí příkazu send a parametru receivers.

Oba způsoby dovozu vzdálených modulů se zapisují stejně jako dovozy místní — v sekci import aplikace:

    import
      remote = '127.0.0.1', 'c:\program files\control web\prog\modul2';
      remote = '194.105.106.107', 'modul3';
      attach = 'technologie.tovarna.cz', 'd:\aplikace\prog\modul4.cw';
    end_import;

Každý dovoz vzdáleného modulu obsahuje nejprve adresu počítače (buď zapsanou přímo jako IP adresa, nebo jako doménové jméno) následovanou cestou k souboru se zdrojovým textem modulu. Všimněte si, že stejně jako v případě lokálních modulů nemusíte u modulů dovezených pomocí remote zadávat cestu k modulu celou — jak adresář tak přípona může být vypuštěna. Při doplňování přípon i adresářů systém postupuje shodně jako v případě místních modulů (způsob doplňování byl popsán v oddíle Dovoz místního modulu a jeho objektů. Avšak pozor, veškerá doplnění přípon i cest vždy uskutečňuje dovážený modul, tedy modul na vzdáleném počítači — použije se tedy přesměrování cizího modulu. Tuto skutečnost je třeba mít neustále na paměti, protože může být zdrojem nejasností.

Dovoz pomocí attach pracuje s cestami k souborů odlišně. Systém při attach dovozu především zjišťuje, zdali požadovaný modul na počítači běží. Toto zjišťování spočívá v prostém porovnání požadovaného jména modulu s úplnými cestami souborů běžících modulů. Zadáte-li proto v dovozu attach neúplnou cestu, nebude modul nikdy nalezen, protože vzdálený systém očekává cestu úplnou (opět se zde jedná o jedno z bezpečnostních opatření, které by systém nemusel obsahovat, ale které zmenšují pravděpodobnost vzniku chyb).

Obecně je možné o cestách vzdálených modulů říci:

- Modul dovezený jako attach musí být zapsán i s celou cestou a příponou.
- Modul dovezený jako remote může být zapsán neúplně, ale kvůli přehlednosti a jednoznačnosti je doporučeno, aby byla cesta vždy uvedena. Naopak přípony modulů dovezených jako remote by se neměly uvádět v případě, že nechcete spustit jednoznačně soubor '*.cw' nebo '*.cwx'.

Poslední zmínka v oddíle je věnována adresám počítačů. Již bylo uvedeno, že identifikaci počítače, kde má být dovážený modul spuštěn, můžete zapsat dvojím způsobem:

- Pomocí jednoduché IP adresy ve tvaru "dotted quad" — jako čtveřici tečkami oddělených čísel v rozmezí 0..255. Takto se běžně zapisují IP adresy v případě, že není známo doménové pojmenování počítače. IP adresy musí splňovat mnoho pravidel, a rozhodně není možné použít jakoukoli adresu. Pokud již počítač IP adresu má (například je-li již počítač součástí podnikové sítě), je pravděpodobně správná a není třeba ji měnit, pokud počítači přiřazujete IP adresu novou, je všechna pravidla zohlednit. O protokolech TCP/IP a o IP adresách se dočtete více v kapitole Co je to TCP/IP.
- Pomocí doménového jména. Doménové jméno počítače je složeno z jednotlivých samostatných slov (domén), která jsou také oddělena tečkou. Počet domén ve jméně není omezen, obyčejně však nepřesahuje počet čtyři (například www.strath.ac.uk). Doménové jméno počítače lze použít jen v případě, kdy existuje v DNS (Domain Name System). Správa a konfigurace doménových jmen přísluší správci domény, který jediný je oprávněn (a schopen) případnou úpravu nebo definici doménového jména provést. Také o DNS a doménách se dočtete více v kapitole Co je to TCP/IP.

### Přenos dat

Na objekty vzdálených modulů se přistupuje zcela identicky, jako na objekty modulů místních. To je velmi důležité, neboť jak s místními tak i vzdálenými moduly můžete pracovat bez rozlišení. Rozdíl mezi použitím místních a vzdálených modulů se tak redukuje de facto pouze na jiný zápis dovozu. Následující text je proto téměř shodný s textem uvedeným při popisu místních modulů:

    a = mod1.a + a;
    ...
    output = mod1.channel_205;
    ...
    send mod1.program_SwitchPanels;
    ...
    mod1.program_SwitchPanels.SetActivePanel( 4 );

Ukázka zobrazuje všechny možnosti použití objektů cizího modulu mod1 dovezeného pomocí remote. V modulech dovezených způsobem attach není možné použít posledních dvou zápisů — poslání zprávy a volání procedury.

Značný rozdíl v přístupu na místní a vzdálené objekty však vyplývá z principu práce. Místní moduly jsou kdykoli dosažitelné, zatímco data modulů vzdálených musí být komunikována. Nejsou tedy okamžitě k dosažení a systém musí (podobně jako u kanálů) zajistit jejich neustálou dostupnost pomocí cache — vnitřní datové oblasti.

Každá komunikace nutně vnáší do programu zpoždění — přenos dat pomocí jakéhokoli média je o několik řádu pomalejší, než přenos dat uvnitř počítače. Aplikace používající vzdálené moduly proto musí počítat s určitým potenciálním zdržením. Pro mezimodulární síťovou komunikaci platí následující pravidla:

- Všechny požadavky na čtení datových elementů jsou okamžitě posílány vzdálenému modulu. Vzdálený modul požadavek bezprostředně vyhodnotí a data pošle zpět. Prodleva mezi vysláním požadavku a přijetím odpovědi značně kolísá a může dosáhnout délky až několika sekund.
- Variabilní délka prodlevy může čekající aplikaci způsobit problémy. Každá komunikace je proto omezena nejdelší prodlevou, kterou komunikace nikdy nepřekročí. Prodleva pro čtení elementů se definuje pomocí parametru receive_timeout sekce network aplikace. Modul na přečtění dat čeká nejvýše stanovenou dobu, takže definujete-li receive_timeout nulový, nebude modul čekat vůbec — po odeslání požadavku se řízení okamžitě vrátí do modulu s předchozí (naposledy přečtenou) hodnotou. Parametr receive_timeout je standardně přednastaven na hodnotu infinite a na čtení datového elementu modul proto standardně čeká.
- Všechny požadavky na zápis se vzdálenému modulu posílají rovněž okamžitě. Vzdálený modul data přijme a zpět posílá pouze potvrzení o dokončené operaci. Stejně jako v případě čtení je délka zápisu omezena prodlevou řízenou parametrem send_timeout sekce network. Standardní hodnota tohoto parametru je nulová, a aplikace proto standardně na zápis hodnoty elementu nečeká.
- Požadavky na čtení i zápis se vyřizují tak jak vznikají. Neexistuje žádný mechanizmus zjišťování, které vzdálené elementy by se měly číst (takový mechanizmus používají kanály) a neexistuje žádný vztah mezi komunikací elementů a časovým krokem. Vzdálené elementy se proto během činnosti přístrojů komunikují při každém použití.

Pro výkon a plynulost běhu aplikace je důležitý především poslední bod. Uvážíte-li, že každý použitý datový element může být komunikován několikrát a že každá komunikace spotřebuje určitý čas, dojdete k celkem neradostným číslům. Například: jedna komunikace trvá na 10MBps síti (to je třeba klasický Ethernet) průměrně 50 milisekund. Čtete-li v přístrojích padesát vzdálených elementů a každý navíc dvakrát, dostanete celkovou délku komunikací 5 sekund! To je překvapivě mnoho, ale násobení jiný výsledek neposkytne. Proto většinou bývá pravidlem, že modul, který požaduje velké množství vzdálených hodnot, nastavuje komunikační prodlevu (receive_timeout) na nulovou hodnotu. Komunikace budou probíhat na pozadí, požadované hodnoty budou ze vzdálených modulů přicházet postupně a aplikace nebude zdržována.

Urychlení komunikace při nulové prodlevě je přitom značné. Síťový komunikační kanál je obousměrný a vznikající požadavky (jak již bylo řečeno) jsou posílány okamžitě. Jelikož nečekající modul požadavky sestaví velice rychle, jsou požadavky také velice rychle a najednou poslány. Vzdálený modul požadavky vyřídí a odpoví na ně také najednou, a všech sto požadovaných hodnot může proto být zpátky v modulu třeba za 80 milisekund (to je hodnota ve srovnání s 5 sekundami velmi malá). Podstata tak velkého urychlení je prostá: čeká-li se na dokončení komunikace, začne nová komunikace až po ukončení komunikace předchozí — délky se sčítají. Nečeká-li se na dokončení komunikace, vyřizují se požadavky současně ("vedle sebe") a najednou je rozpracováno několik komunikací. Výsledný čas je proto jen nepatrně větší, než je délka jedné komunikace.

Komunikace a její ovlivňování (pomocí definic prodlev) může mít kardinální vliv na běh celé aplikace. Volba prodlev je proto velmi důležitá a měla by být proto učiněna s patřičným rozmyslem.

Kromě komunikačních prodlev může běh modulu negativně ovlivnit také větší množství volání procedur. Volání procedury je nepřerušitelná operace — je to vlastně totéž jako volání podprogramu. Volající modul proto vždy musí počkat na dokončení procedury a teprve až po jejím doběhnutí může sám pokračovat. Několik za sebou seřazených volání vzdálených procedur proto může aplikaci značně přibrzdit. Bohužel, princip volání procedur neumožňuje žádnou paralelizaci (která je možná při komunikaci datových elemenů). Není totiž možné, aby bylo najednou rozpracováno více procedur. V distribuovaných aplikacích je proto nutné volání procedur používat s nejvyšší obezřetností.

Stejně jako kanály definují i vzdálené (externí) datové elementy několik atributů, které poskytují informace o průběhu komunikací (atributy jsou pečlivě popsány v kapitole Datové elementy a výrazy). Vzdálené elementy poskytují následující atributy: status, value, timeout, last_ack, requests, hits, rtt a qos. Pozornost si zaslouží atribut timeout.

Vzdálené datové elementy se nijak explicitně nedefinují, a neexistuje proto místo, kde by bylo možné jednotlivým elementům přiřadit specifickou délku komunikační prodlevy. Komunikaci je proto možné řídit pouze globálně, najednou pro všechny elementy zvoleného modulu. To může být nevýhodné. Pomocí atributu timeout jste schopni každému vzdálenému elementu za běhu aplikace dynamicky prodlevu upravovat. Například:

    network
      receive_timeout = 0;
    end_network;
    ...
    program prgReadData;

      procedure OnActivate();
      begin
        a = mod1.Data1;
        if mod1.Data2 then
          mod1.ImportantData:timeout = 5;
          b = mod1.ImportantData;
          mod1.ImportantData:timeout = 0;
        else
          b = mod1.Data3;
        end;
      end_procedure;

    end_program;

Ukázka podle definice parametru receive_timeout nikdy nečeká, přiřazení a = mod1.Data1, b = mod1.Data3 a podmínka if mod1.Data2 proto nezpůsobí nikdy žádné čekání. Avšak přiřazení b = mod1.ImportantData kvůli úpravě parametru timeout na komunikaci vyčká nejdéle 5 sekund. Ukázka tedy pracuje bez prodlev kromě jednoho ručně obsluhovaného datového elementu. Uvedený způsob řízení komunikace uplatníte asi jen v případech, kdy budete potřebovat s jistotou změřit nějaký kritický datový element. Pochopitelně, budete-li element ImportantData komunikovat s prodlevou vždy, je lepší přiřadit do atributu timeout hodnotu jedenkrát — například v přístroji startup — a dále se o ni již nestarat.

Vzdálené moduly mají (stejně jako moduly místní) schopnost samy pohánět cizí jádra a nutit je k měření hodnot. Mechanizmus předávání požadavků i mechanizmus synchronizace měření pracuje stejně jako v případě místních modulů — popis mechanizmů obsahuje oddíl Synchronizace modulů. I u vzdálených modulů proto můžete k řízení synchronizace měření použít obou parametrů — remote_sync a remote_sync_timeout.

### Volby komunikace

Popsaný způsob komunikace vzdálených elementů je možné samozřejmě ovlivňovat mnohem více, než dosud bylo popsáno. Veškerá nastavení síťových komunikací jsou shrnuta do aplikační sekce network. Pro parametry v sekci network platí následující obecná pravidla:

- Zápis parametrů sekce je rozdělen do několika částí. Přímo je možné definovat parametry s platností globální, nepřímo (uzavřeně v sekcích) parametry platné specificky pro vybraný modul.
- Každý parametr má svou počáteční hodnotu, která se použije v případě, že parametr není nikde definován.
- Parametry specifické pro jednotlivý modul je možné definovat zavedením sekce module jméno_modulu ... end_module. Takové parametry mají přednost před globálně nastavenými. Přesně tak lze popsat chování konkrétního modulu a přizpůsobit jej konkrétním požadavkům. V sekci network je možné definovat podsekce module jen pro vzdálené moduly definované v sekci import.
- Do zdrojového textu aplikace se zapisují vždy jen parametry, které mají hodnotu odlišnou od hodnoty počáteční. Viditelné budou tedy jen uživatelem definované parametry.

Jeden z parametrů — options — je zapisován zvláštním aditivním způsobem. Pokud je jeho hodnota odlišná od hodnoty počáteční (default), jsou jednotlivé odchylky přidány spolu se znaménkem + (je-li volba přidána) nebo se znaménkem - (je-li volba odebrána). Zápisy options mohou tedy být například následující:

    options = default - delay_send;
              (* počáteční nastavení bez volby delay_send *)
    options = default + delay_OCL_send;
              (* počáteční nastavení navíc s volbou delay_OCL_send *)
    options = delay_send;
              (* pouze(!) volba delay_send *)
    options = default - delay_send + delayed_OCL_send;
              (* počáteční nastavení s volbou delay_OCL_send a
                 bez volby delay_send *)

Součástí parametru options mohou být následující volby:

- delay_send — parametr určuje, použije-li mechanizmus zpožděného vysílání. V takovém případě se požadavky na vyslání dat postupně shromažďují ve vnitřní vyrovnávací frontě a vlastní vyslání se provede až v okamžiku uplynutí času delayed_send_delay. Dojde tak k tomu, že se najednou posílají větší bloky dat v delších intervalech, čímž se na většině sítí značně zvětšuje propustnost.
- delay_OCL_send — volba tohoto parametru způsobí, že požadavky na volání procedur nezpůsobí okamžité vyslání dosud nashromážděného bloku dat, ale zařadí se stějně jako ostatní požadavky do fronty a jsou vyslány nejpozději po uplynutí času delayed_send_delay.
- delay_core_sync — volba tohoto parametru způsobí, že požadavky na synchronizaci měření dat modulů nezpůsobí okamžité vyslání dosud nashromážděného bloku dat, ale zařadí se stejně jako ostatní požadavky do fronty a jsou vyslány nejpozději po uplynutí času delayed_send_delay. Počáteční nastavení tuto volbu neobsahuje, což umožňuje co možná nejplynulejší chod jednotlivých modulů. Parametr má význam pouze pokud je v daném modulu v sekci settings povolena synchronizace modulů (parametr remote_sync).
- do_io_crash — parametr určuje, vyvolá-li se chyba běhu v případě, že se nějaký datový element nepodařilo přečíst po dobu data_io_crash_timeout.
- is_secure — volba šifrování přenosu dat. Data přenášená mezi počítači je možné šifrovat a chránit je tak před případným zneužitím. Vypnutí této možnosti způsobí nepatrné urychlení komunikace (cca 0,1 %) za cenu otevřeného spojení. Obecné doporučení je ponechat tuto volbu zapnutou.

Počáteční (přednastavená) hodnota parametru options je následující: options = delay_send + is_secure + do_io_crash; Kromě výše popsaných parametrů se navíc mohou při určitých kombinacích v zápise options objevit klíčová slova, která jsou rezervována nebo připravena pro budoucí použití: module_required, do_reconnect, direct_connect, smart_reconnect, do_keep_alive_probe, do_keep_alive_stat, do_polling, do_keep_alive_probe_crash, ack_sent_data. Sekce network (nebo případně vnitřní sekce module) může kromě parametru options obsahovat jestě následující parametry:

- delayed_send_delay — maximální zpoždění vysílání dat. Je-li zapnuta volba delay_send, optimalizuje systém Control Web vysílání dat. Postupně sbírá požadavky na čtení i zápis dat do vnitřní vyrovnávací paměti a posílá je po větších blocích. Parametr delayed_send_delay určuje zpoždění vyprazdňování této vnitřní paměti (periodu vlastního posílání dat). Při volbě větší hodnoty se tak posílají větší bloky dat a naopak. Hodnoty tohoto parametru by měly být relativně malé, nejvíce řádově sekundy.

Počáteční nastavení parametru: 100 milisekund

Příklad — při datovém toku 15 KB za sekundu (cca 700 hodnot za sekundu) se při volbě parametru delayed_send_delay 100 ms bude posílat blok dat cca 1 500 byte desetkrát za sekundu. Takovéto nastavení právě ideálně vytěžuje Ethernet síť — velikost jejího datového rámce je právě 1 500 byte. Sítí v tomto případě projde nejmenší možné množství datových paketů.

- run_remote_side_timeout — maximální čas čekání na spuštění vzdáleného systému Control Web.
- send_timeout a receive_timeout — parametry ovlivňují komunikaci datových elementů. Vzdálené datové elementy nejsou vždy okamžitě k dispozici, k jejich získání je nutné komunikovat se vzdáleným systémem. Při pokusu číst/zapsat data je vzdálenému systému odeslán požadavek, odpověď na něj pak přijde někdy později. Popisovaná klíčová slova umožňují definovat maximální čas, po který se bude čekat na odpověď vzdáleného systému. Velmi velkou hodnotou tohoto parametru tak může být systém donucen čekat na každou požadovanou hodnotu, naopak volbou minimální hodnoty (0) je možné na komunikaci vůbec nečekat, a používat data, která jsou momentálně k dispozici (data z poslední úspěšné odpovědi).

Počáteční nastavení parametrů: receive_timeout = infinite, send_timeout = 0

- data_io_crash_timeout — maximální doba, po kterou komunikační subsystém odpovídá v případě komunikačních potíží na požadavky čtení a zápisu dat bez hlášení chyby. Parametr má význam jen je-li nastavena volba do_io_crash.

Počáteční nastavení parametru: 1 minuta

- invoke_timeout — maximální doba čekání na dokončení volání vzdálené procedury. Volání procedury je v principu nepřerušitelé (atomické), a je nutné i v případě síťového volání počkat na jeho dokončení. V případě, že je vzdálený systém zaneprázdněn, je možné změnou hodnoty tohoto parametru ovlivňovat omezení prodlevy volajícího systému. Hodnota tohoto parametru by neměla klesnout pod průměrnou hodnotu prodlevy volání vzdálených OCL metod. Průměrnou délku volání je možné zjistit v okně s informacemi o síťové komunikaci. V opačném případě je chování systému při volání procedur nedefinováno a v modulu se nelze na výsledky volání spoléhat.

Počáteční nastavení parametru: 2 sekundy

- refuse_authorization_timeout — moduly, které mají povolen attach způsob připojení, mohou při nastavení parametru attach_level vyžadovat autorizaci připojovaného systému. Parametr definuje maximální dobu, po kterou se může připojovaný systém autorizovat. Po uplynutí této doby je vzdálenému připojovanému systému připojení odmítnuto.

Počáteční nastavení parametru: 1 minuta

Následující krátká ukázka demonstruje použití nastavení v sekci network:

    import
      remote = 'pc1.domain.cz', 'm1';
      remote = 'pc2.domain.cz', 'm2';
      remote = 'pc1.domain.cz', 'm3';
    end_import;
    ...
    network
      options = default - delay_core_sync;
      receive_timeout = 0.5;
      module m1;
        receive_timeout = 0;
        options = - do_io_crash;
      end_module;
      module m2;
        send_timeout = 10;
      end_module;
    end_network;

Moduly z příkladu použijí následující parametry:

- moduly m1 a m3 použijí options = deafult - delay_core_sync
- m2 použije options = default - delay_core_sync - do_io_crash
- moduly m2 a m3 použijí receive_timeout = 0.5
- moduly m1 a m3 použijí send_timeout = 0 (to je přednastavená hodnota).

## Nástroje pro tvorbu modulárních aplikací

### Datové inspektory

Všem modulárním aplikacím (jak distribuovaným tak lokálním) je v datových inspektorech vývojového prostředí věnována jedna samostatná záložka "Import". Součástí záložky je jednak definice dovozů (v aplikaci sekce import) a jednak definice síťových parametrů (v aplikaci sekce network). Parametry patřící do sekce network jsou přitom uvedeny přímo u definic jednotlivých vzdálených modulů, což usnadňuje jejich editaci.

Plocha záložky je rozdělena na strom a tabulku, přičemž tabulka vždy obsahuje parametry, které je možné vybranému modulu upravovat. U místních modulů to tedy bude pouze cesta, u vzdálených modulů cesta, název počítače a komunikační parametry. Důležitou částí záložky je strom:

Strom záložky Import

Strom má čtyři kořeny, přičemž klik do každého z kořenů v části s tabulkou zobrazí patřičná data:

- "Network" — tabulka příslušná k tomuto kořenu obsahuje jeden jediný parametr — "Generovat sekci parametrů síťového přípojení". Hodnota parametru řídí, bude-li se do textu aplikace sekce network generovat, či ne. Pokud parametru přiřadíte hodnotu "Ne", neuplatní se žádná síťová nastavení uskutečněná v jiných tabulkách (i při jejich změně bude aplikace stále pracovat s přednastavenými hodnotami).
- "Lokální" — listy tohoto podstromu obsahují všechny místně dovezené moduly (moduly dovezené pomocí local). Klikem na příslušný modul se objeví tabulka, kde můžete upravit jeho parametry. Nový modul zařadíte do aplikace pomocí tlačítka

Nový modul

nástrojové lišty. Podobně vedlejším tlačítkem

Odstranění modulu

vybraný modul odstraníte

- "Vzdálené" — listy tohoto podstromu obsahují všechny vzdálené moduly dovezené pomocí remote. Klikem na příslušný modul se objeví tabulka, kde můžete upravit jeho parametry. Tabulka obsahuje kromě definice cesty modulu a jména počítače také veškerá možná síťová nastavení. Podobně jako u místních modulů můžete tlačítky v liště s nástroji moduly přidávat nebo odstraňovat.
- "Připojované" — listy tohoto podstromu obsahují všechny vzdálené moduly dovezené pomocí attach. Klikem na příslušný modul se opět objeví tabulka s parametry, která opět kromě definice cesty modulu a jména počítače obsahuje veškerá možná síťová nastavení. Tlačítky v liště s nástroji můžete i připojované moduly přidávat nebo odstraňovat.

Všechno ostatní ovládání tabulek i stromů je stejné jako v jiných tabulkách a stromech ve vývojovém prostředí. Pokud vás tedy tyto informace zajímají, přečtěte si sekci O datových inspektorech obecně v kapitole Integrované vývojové prostředí.

### Záložka "Moduly"

Jiným nástrojem, který můžete použít při vývoji modulární aplikace, je záložka "Moduly" vývojového prostředí. V záložce nemůžete upravovat síťové parametry vzdálených modulů, zato ale okamžitě přehledně vidíte, jak se moduly navzájem dovážejí.

Vývojové prostředí při přechodu do záložky "Moduly" simuluje rozběh celé aplikace a analyzuje tak všechny vazby mezi moduly, které se jinak nedají při vývoji zjistit. Simulovaný překlad začíná:

- modulem, který je zaveden do vývojového prostředí v případě, že není definován projekt.
- modulem projektu, je-li definován projekt.

Pokud tedy pracujete s projektem, nemusíte nijak zvlášť přemýšlet nad modulem, který by se měl před přechodem do záložky "Moduly" zavést do vývojového prostředí.

Obsah záložky může vypadat například takto:

Záložka Moduly

Jednotlivé moduly jsou uspořádány na elipse, přičemž nejvýše a uprostřed je umístěn první modul aplikace (to může být projekt, je-li definován). Ostatní moduly jsou uspořádány od prvního modulu proti směru hodinových ručiček v pořadí, v jakém budou systémem spouštěny. Každý modul je symbolizován jménem a ikonou a je navíc doplněn dvěma přípojnými body:

Přípojné body

První přípojný bod (šipka) znamená "dovážím" a odpovídá tedy obsahu sekce import modulu. Druhý přípojný bod (vidlice) znamená "jsem dovážen" a v zápisu zdrojového textu modulů ničemu neodpovídá — jedná se o syntezovanou informaci, kterou je možné získat jedině průchodem všech modulů aplikace. Přípojné body reagují na klik a tažení levého tlačítka myši. Klikněte na přípojný bod se šipkou, tlačítko přidržte a po přetažení do vidlice nějakého jiného modulu tlačítkou pusťte. Modul, který byl cílem tažení, se doveze do modulu, kde tažení začalo. Totéž můžete realizovat i naopak — tažení začněte v nějaké vidlici a ukončete nad šipkou — tato operace dovoz zruší. Pokud je některý modul dovážen jen jedním modulem, zrušíte dovoz také dvojklikem do přípojného bodu s vidlicí.

Asi jste si již všimli, že samotný klik do některého z přípojných bodů automaticky zvýrazní všechny moduly, které se nacházejí na opačných koncích spojů. Tato vlastnost je implementována ryze pro přehlednost.

Kliknete-li nad modulem (nebo nad jeho přípojným bodem) pravým tlačítkem myši, objeví se kontextové menu:

Kontextové menu

jehož součástí jsou všechny operace, které s modulem můžete provést. Všechny operace v menu mají své dvojníky v nástrojové liště:

Lišta s nástroji

Tlačítka v liště po řadě znamenají: "Přidat nový...", "Odstranit...", "Přejmenovat...", "Modul importuje..." a "Modul je importován...". Stejné příkazy byly součástí kontextového menu. Vysvětlení potřebují dva poslední příkazy: "Modul importuje..." a "Modul je importován...". Oba příkazy otevřou dialogové okno (zobrazena je varianta "Modul importuje"):

Okno editace dovozů

V levé části okna jsou zobrazeny všechny moduly buď dovážené, nebo moduly, kterými je modul dovážen. Druhá část potom obsahuje seznam všech ostatních modulů aplikace, které přicházejí v úvahu pro patřičný dovoz. Pomocí tlačítek "Dovézt jako local", "Dovézt jako remote" a "Dovézt jako attach" přesunete modul z pravého seznamu do levého, pomocí tlačítka "Odebrat >>" naopak modul vyřadíte. Otevřete-li okno "Modul importuje...", upravujete sekci import modulu, nad nímž bylo okno otevřeno, otevřete-li okno "Modul je importován...", upravujete sekce import všech modulů mimo modul, nad nímž bylo okno otevřeno.

Poslední užitečnou vlastností je možnost dvojklikem na jméno modulu zavést zdrojový text modulu do textového editoru. Pochopitelně, tato vlastnost pracuje pouze s místními moduly.

## Spolupracující moduly

### Obecná struktura aplikace

V sekci věnované distribuovaným aplikacím bylo poměrně přesně vymezeno, co distribuovaná aplikace dokáže, a co ne. Principem všech těchto úvah byla skutečnost, že dovozem modulů vznikají pevné závislosti, které vyžadují kompletní funkčnost celé aplikace.

V mnoha situacích jsou takové pevné vazby nevhodné. Aplikace spolu sice mohou komunikovat, ale důležitější než vzájemná výměna dat je vlastní běh aplikací. Zároveň je v takových případech možné komunikaci za chodu aplikace opakovaně zahajovat a ukončovat. V každém případě se však již nejedná o distribuovanou aplikaci, ale o více spolupracujících aplikací.

Spolupracující aplikace můžete využít například pro systémy s horkou zálohou, nebo pro systémy, které se samy při běhu musejí dostat postupně na několik jiných aplikací — například aplikace může každý den postupně obtelefonovat měřicí stanice a vyčíst z nich data.

Spolupracující aplikace tedy nejsou implicitně závislé, což značně rozšiřuje oblast jejich použití. Na druhé straně ve spolupracujících aplikací nikdy nezavoláte cizímu přístroji proceduru, ani mu nepošlete zprávu.

V systému Control Web je pro vytváření spolupracujících aplikací určen především TCP/IP ovladač.

### TCP/IP ovladač

Ovladač je určen pro komunikaci mezi několika aplikacemi systému Control Web buď v rámci lokální počítačové sítě (LAN), nebo přes telefonní linky pomocí modemů. Není vyloučeno ani propojení v rámci sítě Internet, neboť ovladač pro komunikaci používá protokol TCP/IP. Pro přenos dat mezi aplikacemi je použito kanálů ovladače. Využívá se architektury klient - server. Každý ovladač může vystupovat jako datový server (poskytuje hodnoty z aplikace, které jsou dostupné jako hodnoty jeho kanálů) a zároveň může být klientem, který čte nebo zapisuje data (opět jsou to jeho kanály) z nebo do jiné aplikace prostřednictvím vzdáleného serveru.

Výhoda použití TCP/IP ovladače je v tom, že aplikace, které běží, mohou být na sobě úplně nezávislé. Každá aplikace pracuje samostatně, to znamená, že se samostatně může spustit i zastavit. Potřebuje-li data z jiné aplikace, přečte si je prostřednictvím klienta ze vzdáleného serveru. Spojení se uskutečňuje buď automaticky při požadavcích na čtení nebo zápis kanálů ze strany klienta nebo na požadavek z aplikace. Automatické spojování nastává v případě, že máte počítače zapojeny do lokální sítě nebo na Internet pomocí pevného spojení. Spojení přes telefonní linky se uskutečňuje vždy na požadavek z aplikace. Jakmile je přenos dat ukončen, může být spojení opět zrušeno.

Snadno se takto dají vytvářet systémy, které používají zálohování - jedna aplikace pracuje (čte data z technologie, ovládá technologii), druhá běží paralelně, ale udržuje si pouze aktuální stavy. V případě výpadku prvního systému druhý automaticky naběhne do plného provozu, to znamená, že převezme všechny úkoly prvního systému. Chyba na prvním systému může být odstraněna a může být opět spuštěn, tentokrát jako záložní.

## Shrnutí

- Control Web dokáže provozovat aplikace sestavené z více modulů. Takové aplikace se jmenují modulární.
- Modulární aplikace může celá běžet na jednom počítači (pak je místní) nebo na více počítačích (pak je distribuovaná).
- Modulární aplikace vzniká dovezením modulu do jiného modulu. Podle druhu aplikace je možné rozeznat dovozy místní (local), vzdálené (remote) a připojované (attach).
- Na objekty cizího dovezeného modulu se přistupuje velmi jednoduše — zápisem prefixu obsahujího jméno modulu. Z cizích modulů je možné používat proměnné a kanály. U modulů local a remote je možné navíc posílat objektům zprávy a volat jim procedury.
- V distribuovaných aplikacích je třeba data mezi moduly přenášet přes síť. Control Web používá pro komunikaci protokolů standardních protokolů TCP/IP.
- Ne vždy je nutné pro výměnu dat použít distribuovanou aplikaci. V mnoha případech postačí pouze aplikace spolupracující. Control Web pro tvorbu spolupracujících aplikací nabízí speciální systémový TCP/IP ovladač.