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ě:

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):

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

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 bez projektu

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

Titulek s projektem

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

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

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ší

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?

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:

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ů

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í:

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:

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á:

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_syncremote_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í:

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:

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

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

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

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:

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:

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:

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:

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:

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:

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:

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:

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 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:

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á:

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

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

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

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

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ů

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í