Zeptáte-li se dnešních studentů oborů informačních technologií, co si představí pod pojmem počítačový „program“ či „aplikace“, zřejmě jen málokdo pod tímto pojmem dnes rozumí jediný spustitelný soubor, ze kterého se zavede kód procesu operačního systému. S propojením počítačů do celosvětové sítě, s příchodem mobilních zařízení jako PDA či „chytré“ mobilní telefony, se standardizací komunikačních protokolů a aplikačních vrstev se význam pojmu aplikace posunuje. Dnes se „aplikací“ rozumí spíše sada komponent a skriptů pracujících na straně serveru i v klientských prohlížečích, komunikujících s databázovým strojem a prostřednictvím HTTP serveru zprostředkovávající informace klientům. Podobu WWW aplikace tak získávají služby jako např. hledání v telefonním seznamu, nalezení místa na mapě, vyhledání autobusových či vlakových spojů apod. Tento koncept aplikací se začíná uplatňovat i mimo prostředí rozlehlého Internetu. Veškeré existující nástroje, znalosti a zkušenosti programátorů lze uplatnit i pro aplikace pracující v prostředí lokálních sítí (intranetů) a stejnou podobu tam může získat třeba účetní systém či skladová agenda firmy. Dokonce i na lokálním počítači existuje řada aplikací, které pro vytvoření uživatelského rozhraní používají stejného konceptu, tedy řadu HTML stránek. S dalším rozvojem různých oborů informačních technologií, jako jsou bezdrátové sítě, přenosné počítače s nízkou spotřebou apod., se tento trend bude dále posilovat.

Aplikace počítačů v průmyslu vykazují často až podivuhodnou rezistenci vůči přílivu nejnovějších technologií a otevřených standardů (tato rezistence je často dobře odůvodněna požadavky na maximální spolehlivost a robustnost, na druhé straně stejně často je hlavní příčina v neochotě naučit se cokoliv nového i pokud nová technologie výrazně zvýší užitečnost aplikace a zlevní řešení). Přesto výhodnost internetových a intranetových řešení pro celou řadu aplikací je natolik zřejmá, že začínají pronikat i do tohoto konzervativního odvětví. Internetový prohlížeč (WWW browser) je dnes přítomen na každém počítači a stejně tak každý počítač v podnikové sféře je zapojen do sítě. Možnost zpřístupnit vizualizaci a případně i řízení průmyslového procesu z libovolného počítače se tak pro zákazníky stává velikým lákadlem.

Samozřejmě nelze od vizualizace v prostředí WWW prohlížeče očekávat stejné možnosti jako od aplikačního programu pracujícího na lokálním počítači. V prostředí prohlížeče jsme omezeni internetovými standardy formátů dokumentů a obrázků, možnostmi programování (skriptování), standardy pro zabezpečení apod. Další omezení se týkají např. reakčních dob systému na požadavky na komunikaci s PLC nebo měřicími jednotkami apod. Zatímco lokálně běžící aplikace musí být schopna řídit komunikaci v reálném čase a případně reagovat na zpoždění či poruchy komunikace, realizovat stejnou funkci (se srovnatelnou dobou odezvy) v prostředí WWW prohlížeče je téměř nemožné. Přitom platí jedno pravidlo – čím širší má být okruh klientů schopných k aplikaci přistoupit (např. pomocí různých typů prohlížečů pracujících na různých operačních systémech), tím více omezení bude na aplikaci kladeno. Extrémem může být např. aplikace pracující na miniaturních zobrazovačích mobilních telefonů, pro jejichž tvorbu musíme vystačit s elementárním HTML kódem a jediným formátem obrázků.

Přítomnost zabudovaného HTTP serveru, díky němuž mohou k aplikaci přistupovat klienti prostřednictvím WWW prohlížečů, byla jedním z důvodů pojmenování programového systému pro rychlý vývoj průmyslových vizualizačních a řídicích aplikací Control Web. Ačkoliv v první verzi systému Control Web 3 byl HTTP server vhodný spíše pro menší aplikace v rámci intranetu, narůstající požadavky zákazníků vedly k podstatnému rozšíření funkčnosti, usnadnění programového řízení, zpřístupnění hlaviček HTTP protokolu, zvyšování robustnosti (např. detekci a odražení pokusů o získání kontroly nad serverem útokem typu „buffer overrun“) apod. Všechny tyto inovace vedly k verzi HTTP serveru v systému Control Web 5 schopné plnohodnotně pracovat nejen jako WWW brána do technologického procesu, ale také v roli podnikového WWW serveru s kompletním redakčním systémem, schopným obsloužit velké množství klientů. Protože statické, „ručně“ tvořené HTML stránky již neodvratně patří minulosti, samozřejmě na tuto roli nestačí HTTP server sám, ale potřebuje k tomu další komponenty systému Contorl Web, především pro přístup k SQL databázím. Klíčovou roli při tvorbě takových webových aplikací sehrává výkonný skriptovací jazyk systému Control Web.

Generování HTML stránek

Přístup k WWW stránkám je dnes již považován za naprostý základ počítačové gramotnosti – v žádném kurzu používání počítače se s WWW prohlížečem nelze minout. Povědomí co se za WWW službou skrývá ale už zdaleka není běžné, i když samotný princip je velmi jednoduchý.

Aby si dva počítače mohly vyměňovat data, musí oba používat stejný dorozumívací jazyk. Protokol užívaný při komunikaci mezi klientem a serverem služby WWW nese označení HTTP (z anglického Hyper-Text Transfer Protocol). V prostředí Internetu jsou používány i další protokoly, např. SMTP pro přenos elektronické pošty, FTP pro přenos souborů apod. Nedejme se ale zmýlit názvem protokolu, HTTP lze použít k přenosu jakýchkoliv dat, nejen hypertexů. Pomocí HTTP lze přenášet obrázky, spustitelné binární soubory, komprimované archivní soubory apod. Protože server služby WWW komunikuje s klienty pomocí HTTP protokolu, bývá také nazýván HTTP server.

Když pomineme technické detaily navazování síťového spojení na portu služby HTTP serveru, celé kouzlo WWW spočívá v odesílání HTTP požadavků z klientské aplikace k serveru, na které server odesílá HTTP odpovědi. Základním požadavkem je požadavek typu GET – získej data. O jaká data má klient zájem určuje tzv. URL (z anglického Universal Resource Locator). URL má v prostředí WWW podobnou funkci jako jméno souboru na lokálním počítači – pojmenovává zdroj dat. URL ale navíc může nést další informace a parametry pro server.

Jak s daty naložit je už záležitost klientské aplikace (WWW prohlížeče). Pokud server poskytne HTML soubor (textový soubor formátovaný podle pravidel HTML – Hyper-Text Markup Language), prohlížeč jej zformátuje podle značek v souboru obsažených (značky určují např. nadpisy, dělení odstavců apod.). HTML stránka ale může obsahovat další data, např. obrázky. Obrázky ale nejsou obsaženy přímo v textu HTML souboru, ale ve stránce je na ně uveden pouze odkaz v podobě URL. Klient pak pošle další dotaz serveru s danou URL a server odpoví blokem dat, tentokráte obsahujícím požadovaný obrázek. Vrácený obrázek pak klient zobrazí v rámci stránky.

Podobnost URL se jménem souboru svádí k představě, že HTTP server pouze převede URL obdrženou od klienta na jméno lokálního souboru a tento soubor klientovi vrátí. V případě statické WWW aplikace je tomu skutečně tak – všechny HTML dokumenty, obrázky a další soubory tvořící aplikaci jsou připraveny na disku a HTTP server je čte a odesílá klientům. Nevýhoda takové aplikace je ale velmi pracná údržba. Jakákoliv změna v řadě dokumentů provázaných hyper-textovými odkazy je obtížná a zdlouhavá. Žádná rozsáhlejší WWW aplikace takto konstruována není prostě z důvodu naprosté neudržovatelnosti. Řešení je zřejmé – na místo statické struktury souborů na straně serveru běží aplikace, která obsahy stránek vytváří algoritmicky.

Jako příklad můžeme uvážit úvodní stránku WWW aplikace, která má obsahovat odkazy na články vložené za poslední týden. Ruční údržba takové stránky by představovala neustálé sledování nově vložených článků a dopisování odkazů na ně do HTML souboru představujícího úvodní stránku, a také odmazávání starších odkazů. Naproti tomu u stránky tvořené kódem procedury probíhá vše automaticky. Procedura se dotáže SQL serveru na články s datem vložení nejpozději 7 dní pozpátku a algoritmicky vytvoří HTML dokument, který odešle klientovi. Klientská aplikace samozřejmě nemůže rozlišit jak HTML dokument, který jí poslal server vznikl a nakonec to ani nepotřebuje. Jestliže dokument odpovídá pravidlům HTML, může jej korektně zobrazit. To je celé kouzlo dynamické WWW aplikace.

Pro ilustraci uveďme elementární příklad dynamické tvorby kořenové stránky v systému Control Web 5:

httpd WebServer;
  pages
    item
      path = '/';
      call = GenerateIndex();
    end_item;
  end_pages;
    
  procedure GenerateIndex();
  begin
    PutText('<html><head><title>Ukázka</title></head>');
    PutText('<body>Stránka generovaná dynamicky</body></html>');
  end_procedure;
end_httpd;

Pokud WWW prohlížeč odešle serveru dotaz s URL ‘/’ (základní nebo tzv. indexová stránka), server ví že tento soubor nemá hledat na disku, ale k jeho vytvoření má zavolat proceduru GenerateIndex. Kód této procedury vytvoří text stránky postupným voláním PutText. WWW prohlížeč obdrží HTML dokument:

<html><head><title>Ukázka</title></head>
<body>Stránka generovaná dynamicky</body></html>

a jak bylo řečeno dříve, není schopen rozlišit, zda tento dokument byl uložen v podobě souboru na disku nebo zda byl vytvořen algoritmicky.

V případě jednoduché stránky nepřináší dynamické generování žádné zjevné výhody, snad mimo skutečnost, že celá WWW aplikace může pracovat zcela bez přístupu na disk. Uvažme ale následující proceduru GenerateIndex:

procedure GenerateIndex();
var
  i : integer;
begin
  access_count = access_count + 1;
  PutText('<html><head><title>Dynamická tránka</title></head><body>');
  if display_table then
    PutText('<table border="1" width="30%" align="center">');
    for i = 1 to lines do
      PutText( '<tr><td> řádek </td><td> ' + str( i, 10 ) + 
               ' </td></tr>' );
    end; (* for *)
    PutText('</table> ');
  else
    PutText('<center><ul>');
    for i = 1 to lines do
      PutText( '<li> řádek ' + str( i, 10 ) + '</li>' );
    end; (* for *)
    PutText('</ul></center>');
  end;
  PutText('<hr><b>Stránka vygenerována ' + date.TodayToString() + 
          ' v ' + date.NowToString() + '.<br>Počet přístupů: ' + 
          str( access_count, 10 ) + '</b>');
  PutText('</body></html>');
end_procedure;

V tomto případě je výhoda dynamického generování již zjevná. Především jediná procedura tvoří HTML text odpovídající tabulce nebo seznamu na základě nějaké podmínky. Dále stojí za zdůraznění, že délka stránky není předem dána, ale záleží na hodnotě proměnné lines. Na samém konci stránky je zobrazeno počitadlo přístupů, aktuální datum a čas. Každý klient vždy přečte ze serveru HTML dokument s jiným textem (lišící se minimálně zobrazeným počtem přístupů a také datem a časem), i když požádá o stejnou stránku.

Aplikace nebo jen prohlížení dokumentů?

Prapůvod služby WWW leží v systému zpřístupňujícímu vědcům dokumenty v evropském středisku jaderného výzkumu CERN. Možnost zabudovat do textu odkaz na jiný dokument (odtud název hyper-text) dělá z obyčejných textů jednoduchou aplikaci, reagující na přání uživatele – kliknutí na odkaz způsobí zavedení nového dokumentu do prohlížeče. Pokud by možnosti HTML zabudováním odkazů na jiné soubory do textu končily, asi bychom nemohli hovořit o aplikačním prostředí. Popularita WWW ale zapříčinila prudký vývoj tohoto standardu a postupně začaly přibývat možnosti nejen zabudování obrázků do dokumentu, přesnějšího formátování, ale také možnosti tvorby formulářů, v nichž uživatelé mohou zadávat data pro aplikaci. Vývoj se ale nezastavil a HTML standard obsahuje možnost psaní skriptů (skripty v HTML stránce představují programový kód, který je ve WWW prohlížeči vykonáván), kaskádní styly, dynamické HTML apod. Dnes tedy už můžeme hovořit o HTML jako o relativně bohatém a mocném aplikačním prostředí.

Součástí definice protokolu HTTP je mimo požadavků čtení dat ze serveru (metodou GET) i zápis dat na server metodou PUT. V praxi se ale této metody nepoužívá, protože není podporována klientskými aplikacemi a především obsahuje řadu bezpečnostních rizik – v principu je nemyslitelné, aby klienti ukládali soubory na server na zadané URL. Proto je odesílání dat od klienta na server omezeno na dvě metody protokolu HTTP:

• Lze použít metody GET s daty zakódovanými v URL.

• Přímo k odesílání dat na serveru je určena metoda POST.

Poznamenejme, že HTTP protokol nedefinuje mechanizmy zpracování dat. Záleží výhradně na serverová aplikaci jak s daty naloží.

Ačkoliv je metoda POST původně navržena pro odesílání dat z HTML formulářů, byla rozšířena i o možnost odesílání celých souborů. Na rozdíl od metody PUT ale v tomto případě URL neurčuje kam daný soubor na serveru uložit, ale spíše definuje která část serverové aplikace bude soubor zpracovávat. Jak se souborem naložit je opět záležitost implementace serverové aplikace – např. může uložit soubor do databáze apod.

Systém Control Web nabízí řadu způsobů zpracování dat odeslaných uživateli na server.

• Nejjednodušším způsobem je definování vazeb mezi jmény ovládacích prvků v HTML stránce a datovými elementy v aplikaci. Pokud uživatel odešle data z formuláře do aplikace, patřičné datové elementy nabudou hodnot vyplněných ve formuláři.

• Pokud je část nebo celá HTML stránka tvořena kódem procedury, může programátor pomocí procedury GetURLData získat řetězec, který obsahuje jména a hodnoty ovládacích prvků z formuláře. Je pak na programátorovi, aby z tohoto řetězce získal patřičné hodnoty.

• Protože GetURLData lze volat jen z procedury reagující na požadavek GET, data zasílaná metodou POST lze zachycovat procedurou OnFormData. Tato procedura je volána vždy když serveru přijdou data z formuláře, ať již metodou GET nebo POST.

• Pokud aplikace využívá rozšíření metody POST dovolující uživatelům odesílat na server celé soubory, může využít událostní procedury OnPostFile.

Zde můžeme konečně vysvětlit odkud se vzaly hodnoty proměnných display_table a lines v předchozím příkladu. HTML formulář obsahuje ovládací prvky pojmenované a pokud je formulář odeslán serveru, jména a hodnoty těchto ovládacích prvků jsou připojeny do URL:

http://localhost/default.htm?display_format=true&line_count=10

V HTTP serveru pak stačí uvést mapování mezi jmény ovládacích prvků a jmény proměnných v aplikaci:

httpd WebServer;
  static
    lines : integer;
    display_table : boolean;
    access_count : longint;
  end_static;

  forms
    item
      id = 'line_count';
      output = lines;
    end_item;
    item
      id = 'display_format';
      output = display_table;
    end_item;
  end_forms;
  ...
end_httpd;

Problémy může způsobovat nejednoznačnost definice chování serveru při odpovědi na metodu POST v rámci standardu HTTP. Součástí POST je totiž URL, definovaná atributem ACTION v definici formuláře v HTML dokumentu. Dle definice tato URL ale slouží k identifikaci entity, jíž se data odesílaná v rámci POST týkají. Není specifikováno, zda-li mají být data odkazované URL v POST vrácena (stejně jako po GET) či nikoliv. Praktické zkušenosti ukázaly, že optimální chování serveru po POST, maximálně ulehčující tvorbu WWW aplikací, je chování odpovídající metodě GET. Existují-li data odkazovaná v URL u POST, jsou vrácena s kódem 200 OK, pokud data ale neexistují, není vráceno 404 Not Found jako po GET, ale 204 No Content.

Optimalizace datového toku po TCP/IP síti

Mechanismy vyrovnávacích pamětí, kdy jsou data dočasně uchovávána v místě potřeby a nikoliv pokaždé přenášena z trvalého uložení, se ukázaly jako mocný způsob zrychlení a zefektivnění práce v řadě technických i programových systémů. Kupříkladu vyrovnávací paměť v procesoru mu umožní pracovat mnohonásobně rychleji než by mu umožnila rychlost pamětí, vyrovnávací paměť disku zvýší jeho efektivní přenosovou rychlost apod.

Stejným způsobem mohou vyrovnávací paměti HTTP protokolu výrazně urychlit zpřístupnění WWW stránek. WWW stránky obsahují řadu statických obrázků, které se po dlouhou dobu nemění a je zbytečné aby je prohlížeč pokaždé ze serveru zaváděl. Z tohoto důvodu si každý prohlížeč uschovává určité množství dokumentů a obrázků na lokálním disku počítače, odkud je může zavést a zobrazit nepoměrně rychleji než po seberychlejší IP síti.

V rámci Internetu i intranetů se lze setkat se specializovanými servery pracujícími jako vyrovnávací paměť HTTP protokolu. Pokud více klientů (např. v rámci podnikové sítě) nepřistupuje na vzdálený server přímo, ale prostřednictvím tzv. proxy-serveru, mohou tito klienti výrazně zrychlit přístup k WWW stránkám. První klient způsobí zavedení stránek do vyrovnávacího serveru, v případě dalších klientů se vyrovnávací sever pouze ubezpečí, zda data na původním serveru nebyla změněna a pokud ne, vrátí data ze své vyrovnávací paměti na místo jejich pomalého přenosu přes Internet. Oba mechanizmy (vyrovnávací paměť WWW prohlížeče i specializované vyrovnávací servery) jsou si velmi podobné a využívají velmi podobných mechanizmů.

Klíčová otázka v každém systému s vyrovnávací pamětí je zajištění konzistence dat. Pokud se např. obrázek na serveru změní, bylo by od klienta chybné zobrazovat obrázek uložený v lokální vyrovnávací paměti. Ovšem klient nemá jinou možnost jak zjistit aktuálnost své vyrovnávací paměti než dotázat se serveru. S každým blokem dat přenášeným HTTP protokolem (pod blokem dat rozumíme např. HTML dokument, obrázek apod.) je přenášena informace o okamžiku poslední modifikace. Klient tedy ví, jak starý je dokument uložený v lokální vyrovnávací paměti, musí jen zjistit stáří právě aktuálního dokumentu na serveru.

K tomu byla do HTTP protokolu zabudována další metoda nazvaná HEAD. Tato metoda odpovídá metodě GET (obsahuje URL i další údaje v požadavku), ovšem klient očekává jako odpověď pouze hlavičku bloku dat. Protože hlavička obsahuje informace o čase poslední modifikace, může se klient rozhodnout, zda o data požádá tentokráte metodou GET nebo zda použije data z lokální vyrovnávací paměti.

Použití dotazu HEAD může ušetřit zbytečné přenosy, pokud ale dokument není aktuální, znamená prodloužení přenosu o jeden dotaz HEAD a odpověď. Z tohoto důvodu bývá v prostředí Internetu používána alternativní metoda. Klient požádá o data server metodou GET, ale do protokolu uvede hlavičku informující server aby data odeslal jen pokud byla modifikována od zadaného data odpovídajícího datu poslední modifikace dat v lokální vyrovnávací paměti. Server sám posoudí aktuálnost dat a pokud jsou k dispozici data novější, přímo odpoví. Pokud ne, informuje klienta, že data nebyla modifikována a žádná data neodesílá. Tento způsob zaručuje skutečně minimální zatížení sítě a optimální přenos dat. HTTP server v systému Control Web podporuje oba způsoby optimalizace přenosu.

Výše popsané mechanismy si lze velmi snadno představit u statických dokumentů uložených jako soubory. Okamžik poslední modifikace každého souboru je zapsán v souborovém systému a HTTP server jej může využít. Pokud je ale dokument generován dynamicky, situace se velmi komplikuje:

• U dynamického generovaného dokumentu je okamžik poslední modifikace vždy nastaven na aktuální čas. Klient tedy nikdy nemůže mít aktuální verzi a vždy musí přenést data ze serveru.

• Ne vždy se ale dynamicky generovaná stránka skutečně liší od stránky generované předchozím dotazem. Pokud např. algoritmus slouží pouze k dekódování URL a vrácení dat uložených v databázi, je zbytečné nastavovat okamžik poslední modifikace na aktuální datum a čas. Pomocí procedury SetLastModified může klient nastavit okamžik poslední modifikace a Control Web HTTP server automaticky vrátí data klientovi nebo mu oznámí že data nebyla modifikována. Ačkoliv u WWW serverů nebývá limitní výkon počítače, ale kapacita přenosových linek, procedura generující stránku může voláním GetHeader zjistit hodnotu hlavičky If-Modified-Since a rozhodnout se zda-li je zapotřebí stránku vygenerovat či ne. Pokud voláním SetLastModified nastaví datum rovné (nebo menší než) datu v hlavičce If-Modified-Since, server klientovi odpoví kódem 304 Not Modified a tak není nutno ztrácet čas vytvářením stránky.

• V případě že algoritmus generující stránku pouze přesměruje datový tok do souboru voláním RedirectToFile, jako okamžik poslední modifikace také nebude použit okamžitý čas, ale čas poslední modifikace souboru.

Control Web dokáže dynamicky generovat dokumenty zcela bez zásahu uživatelského programu. Pokud kupříkladu chceme WWW prohlížečům přenášek okamžitou podobu nějakého virtuálního přístroje, zajistíme to velmi jednoduchým mapováním URL obrázku na viditelný virtuální přístroj v aplikaci:

httpd WebServer;
  instruments
    item
      path = '/img1';
      instrument = panel_energie;
    end_item;
    item
      path = '/img2';
      instrument = panel_voda;
    end_item;
    ...
  end_instruments;
  ...
end_httpd;

Kdykoliv se HTML stránce objeví odkaz na obrázek „img1“, server nebude prohledávat disk (soubor s tímto jménem by ani nenalezl), ale vykreslí okamžitou podobu přístroje se jménem panel_energie. V tomto případě je okamžik poslední modifikace vždy nastaven na aktuální čas.

Control Web 5 jako HTTP server http://www.mii.cz

Mocnost HTTP serveru zabudovaného do systému Control Web 5 dokazuje aplikace vyvinutá pro běh na serveru http://www.mii.cz. Aplikace obsahuje nejen „klientskou“ část, která zobrazuje data návštěvníkům serveru (čtete-li tento článek na serveru www.mii.cz, data pro Vás připravil Control Web), ale taká administrativní část umožňující pohodlnou administraci celého serveru.

Serverová aplikace odpovídá všem nárokům na moderní informační WWW server:

• Veškeré texty jsou ukládány ve formátu XML užívajícím jednotnou definici typu dokumentů. Tím je zaručeno jednotné a konzistentní formátování v rámci všech stránek. Změnou XML transformací lze najednou změnit vzhled všech textů. Server tak zcela odděluje obsah dat a jejich formátování.

• Žádná data nejsou uložena staticky. Veškeré texty jsou generovány do HTML formátu ze zdrojových XML souborů dynamicky za běhu aplikace.

• Veškerá data jsou uložena v SQL databázi. Datový obsah tak lze jednoduše zálohovat či replikovat.

• Vzhled stránek je definován algoritmicky na základě struktury dat. Pokud např. do nabídky firmy přibude nový produkt, stačí přidat do aplikace jeho popis a zařadit jej do patřičné kategorie. Anotace s odkazy na detailní popis se automaticky objeví v produktové stránce, případně ve stránce novinek apod.

• Zcela automatizovaná je podpora vládání obrázků do dokumentů. Index obrázků je uložen v databázi a tak potenciální výměna obrázků je snadnou záležitostí. V rámci transformace XML do HTML jsou podle atributů s obrázkem spojených automaticky generovány malé či velké náhledy, odkazy na obrázek v plném rozlišení apod.

Tvůrci obsahu mají k dispozici administrativní rozhraní, umožňující měnit strukturu kategorií a přidávat či modifikovat články, popisy, obrázky apod. Celé rozhraní pracuje v rámci standardního WWW prohlížeče, z důvodů bezpečnosti lze přístup k tomuto rozhraní omezit nejen jménem či heslem, ale také určitými IP adresami či maskami IP sítí.

Základní operace s kategoriemi (přepojování podkategorií, editace anotace apod.) jsou implementovány pomocí HTML formulářů. Nicméně editační možnosti ovládacích prvků HTML formulářů jsou natolik omezené, že komfortní editace delších článků se složitějším formátováním je prakticky nemožná. Proto systém nabízí stažení zdrojového tvaru článků v XML formátu na lokální počítač, kde je možné článek editovat jakýmkoliv XML editorem. Poté je možné XML opět nahrát na server. Serverová aplikace zkontroluje správnost odkazů a dostupnost obrázků a případně vyzve uživatele k zadání umístění obrázků na lokálním počítači, automaticky je přenese na server a zařadí do databáze.

Aplikace http://www.mii.cz/ demonstruje pouze malou část schopností systému Control Web zaměřenou na tvorbu distribuovaných aplikací v prostředí Internetu a intranetů pro klienty používající WWW prohlížeče. Velké množství dalších oblastí, jako např. tvorba distribuavaných aplikací založená na „tlustých klientech“, sdílených a synchronizovaných datových sekcích, automatické generování DHTML aplikací, pokročilá 3D vizualizace procesů atd. ale mnohonásobně přesahuje možnosti tohoto článku.