TCP/IP

Jak již bylo řečeno, pod pojmem Internet se nerozumí nějaká konkrétní síť, ale spíše propojení existujících počítačových sítí, dodržujících standardy rodiny protokolů TCP/IP. Označení TCP/IP je poněkud matoucí, neboť zkratky TCP a IP označují různé součásti celé rodiny protokolů a mnohé služby protokol TCP vůbec nepoužívají. Toto označení je ale natolik rozšířené, že jej všichni akceptují.

Podrobné vysvětlení protokolů TCP/IP a jejich konfigurace naleznete v řadě publikací (např. W. Richard Stevens, TCP/IP Illustrated, Volume 1 a 2, 1994 Addison-Wesley). Zde se spokojíme jen se stručným přehledem. Jako většina technických problémů je i komunikace v počítačové síti řešena na několika úrovních. Nižší úrovně jsou méně abstraktní, poskytují základnější služby. Naopak vyšší úrovně poskytují kvalitnější služby, ale používají k tomu služeb nižších úrovní.

Na základní úrovni musí existovat nějaké fyzické médium a základní způsob výměny dat po tomto médiu, např. síťové karty standardu Ethernet, kabely a přepínače apod. Někdy bývá tato úroveň označována jako dvě vrstvy -- kabely tvoří základní vrstvu a např. protokol Ethernet tvoří další vrstvu.

Nad touto základní úrovní pracuje první člen rodiny protokolů TCP/IP -- protokol IP (Internet Protocol). Protokol IP dokáže v podstatě jen odeslat balík dat (nazývaný IP paket) z jednoho počítače na druhý. Aby bylo možno počítače rozlišit, musí mít každý počítač přiděleno unikátní (v celé síti jedinečné) číslo, nazývané IP adresa. IP adresa je 32-bitové (4 byte) číslo, existuje tedy více než 4 miliardy IP adres. Z organizačních důvodů bývají tyto adresy zapisovány jako čtveřice čísel oddělených tečkou, každé v rozsahu 0 až 255 (každá číslice reprezentuje jeden byte), např. 194.108.72.1. IP adresa ale nemůže být prostě jen nějaké číslo, byť by bylo skutečně jedinečné. Důvod je ten, že neexistuje (ani nemůže existovat) přímé propojení mezi všemi počítači do Internetu zapojenými. Jestliže je tedy nutno poslat IP paket z jednoho počítače na druhý, zpravidla musí tento paket projít menším či větším počtem jiných počítačů, zvaných směrovače (routery). Aby směrovače poznaly, kam mají IP paket odeslat, musí IP adresa odpovídat ještě dalším pravidlům. IP adresu si tedy nemůžete vymyslet, musíte ji obdržet od vašeho správce sítě nebo ji musíte se znalostí věci vhodně zvolit z intervalu adres vaší sítě.

V naprosté většině případů aplikace nepoužívají přímo protokol IP, i když by to bylo v zásadě možné, ale zbytečně komplikované. Proto nad IP protokolem existují další protokoly pro přenos dat, např. UDP (User Datagram Protocol) nebo TCP (Transmission Control Protocol). UDP a TCP se zásadně liší.

UDP je protokol schopný odeslat blok dat z jednoho počítače na druhý bez ustavení spojení mezi oběma počítači. Je poměrně rychlý, ale nezaručuje spolehlivé spojení - pokud se UDP paket po cestě ztratí, aplikace sama musí na tuto situaci reagovat. Taktéž pokud jedna aplikace odešle několik UDP paketů, druhá aplikace je může obdržet v libovolném pořadí.

TCP protokol vyžaduje nejprve navázání spojení mezi počítači a sám hlídá doručení paketů a jejich opakované vyslání v případě ztráty. Rovněž zaručí zachování pořadí odeslaných a přijatých paketů. TCP protokol tedy poskytuje aplikacím vyšší úroveň služeb, ale platí za to nižším výkonem.

Nad protokoly TCP a UDP již mohou pracovat přímo aplikace, např. distribuovaný průmyslový řídicí systém Control Web inicializuje spojení pomocí protokolu UDP, vlastní komunikace probíhá přes TCP. Nad TCP mohou pracovat protokoly ještě vyšší úrovně, např. protokol pro přenos souborů FTP (File Transfer Protocol) a HTTP (HyperText Transfer Protocol), nejnovější verze protokolu pro sdílení souborů v prostředí UNIX NFS nebo protokol pro přenos elektronické pošty SMTP.

Tento popis je jen velmi povrchní a neobsahuje celou řadu daších protokolů a služeb nutných ke spolehlivému fungování Internetu. Pro základní orientaci ale naprosto stačí.

Lidé si mnohem snáze pamatují jména než čísla. Pokud chcete zadat IP adresu nějakého počítače v Internetu, je velmi obtížné zapamatovat si ji přímo jako číslo. Navíc pokud uvidíte číselný zápis IP adresy nějakého počítače, vůbec z něj není patrné o jaký počítač se jedná. Proto se v rámci Internetu rozšířila služba nazývaná DNS (Domain Name Service). Tato služba využívá hierarchického (stromového) členění jmen na tzv. domény. TCP/IP dokáže pomocí postupných dotazů přeložit textově zadané jméno počítače na IP adresu, která mu odpovídá a tuto adresu pak používá ve vzájemné komunikaci.

Každý název počítače zapojeného do Internetu se skládá několika jmen oddělených tečkami. I když na první pohled může použití teček připomínat tečky v zápisu IP adresy, tato podobnost je čistě náhodná. Jednotlivá jména reprezentují jednotlivé domény, uspořádané do stromové struktury. Nejvíce napravo zápisu jsou domény nejvyšší úrovně (top-level domény), zpravidla reprezentující stát. Např. cz je Česká Republika, uk Velká Británie apod. Protože Internet se začal rozvíjet v USA jako vnitrostátní záležitost, vznikla řada domén nejvyšší úrovně bez uvedení státu, jaksi "samozřejmě" se předpokládá, že patří do USA: com reprezentuje firmy komerční sféry, gov vládní instituce, edu vzdělávací instituce a školy, net organizace zajišťující běh sítě apod.

Pak např. jméno www.mii.cz bude přeloženo na IP adresu 194.108.72.1, aniž by si tuto adresu kdokoliv musel pamatovat. Stačí si zapamatovat, že firma Moravské přístroje (Moravian Instruments, Inc.) z České Republiky má doménu mii.cz a že chcete server služby www.

Před doménou nejvyšší úrovně je zpravidla jméno dané instituce nebo firmy. Řada firem ale nevlastní celou síťovou infrastrukturu a může využít služeb nějaké jiné firmy a pak se její jméno může objevit až jako třetí úroveň.

Internet a intranet

Rozvoj Internetu s sebou přinesl rychlý vývoj a současně standardizaci celé řady komponent informačních systémů - počínaje síťovými protokoly TCP/IP, FTP, HTTP, SMTP apod. přes zařízení pro budování sítí, směrovače, až po aplikace, jako např. FTP a HTTP servery, klientské aplikace elektronické pošty, WWW prohlížeče apod.

Všechny tyto komponenty pracující na Internetu lze samozřejmě s výhodou použít i pro budování interních podnikových informačních systémů namísto vlastnických řešení jednotlivých firem. Z technologického hlediska není mezi Internetem a vnitřní podnikovou sítí žádný rozdíl. Tak vznikl termín intranet - vnitřní podniková síť využívající internetových technologií.

Protože intranet zpravidla nebývá rozprostřen po celé zeměkouli, většinou bývají jednotlivé intranetové servery připojeny podstatně rychlejšími linkami než internetové servery. Taktéž se v rámci intranetu zpravidla přenáší citlivá podniková data a tak intranety bývají od Internetu chráněny speciálním počítačem zvaným firewall (ohnivá zeď), bránícím nepovoleným osobám zvenku přistupovat k utajeným datům, či dokonce bývají od Internetu úplně odpojeny.

Výše popsaný princip se bez výjimky vztahuje i na průmyslový informační a řídicí systém Control Web. Distribuované a modulární aplikace i vizualizace a řízení prostřednictvím WWW, popsané dále, lze realizovat na libovolné IP síti. Platí tedy, že aplikaci systému Control Web lze stejně tak distribuovat v rámci relativně pomalých spojení celosvětového Internetu jako i v rámci uzavřeného podnikového intranetu, využívajícího rychlých spojení lokálních sítí.

WWW - World Wide Web

Princip funkce WWW je velmi jednoduchý. Kdo chce prezentovat nějaké informace, umístí na počítač zapojený do Internetu program zvaný server, který dokáže odpovídat na požadavky uživatelů (klientů) a poskytovat jim data. Uživatel pak musí zadat internetové jméno počítače (serveru) a server pak poskytne požadovaná data klientskému počítači.

Ve skutečností to ale až tak jednoduché samozřejmě není. Aby se dva lidé domluvili, musí hovořit stejným jazykem a s počítači je to také tak. Bylo tedy třeba definovat standardní způsob výměny informací nazývaný protokol. V případě služby WWW se jím stal protokol HTTP (HyperText Transfer Protocol). Stejný jazyk je sice nutnou podmínkou dorozumění, sám o sobě je ale nezajišťuje. Jestliže server pošle data klientovi a klient data přijme, je nutno je prezentovat uživateli a umožnit mu se v nich orientovat - to je možné, pokud data vyhovují dalšímu standardu, formátu HTML (HyperText Markup Language). HTML definuje standardní způsob, jak formátovat text, jak zvýraznit nadpisy, jak do textu začlenit obrázky apod. Velmi podstatnou částí HTML je možnost umístit do textu odkaz na jiný zdroj informací - tzv. hyperlink (odtud slovo HyperText v názvu komunikačního protokolu i formátu dokumentů).

Naposled jmenovaná vlastnost HTML je z uživatelského hlediska velmi příjemná. Není nutno vždy zadávat zdroj informace (umístění dokumentu nebo jméno serveru). Autoři HTML dokumentů umístí jméno nového dokumentu jako odkaz do svého dokumentu a uživateli pak stačí na odkaz jenom kliknout. WWW prohlížeč načte nový dokument a zobrazí jej.

HTML dokumenty bývají pojmenovávány podle pravidel shrnutých do označení URI (Universal Resource Identifier). URI je textový řetězec obsahující identifikaci protokolu (v našem případě http), dále jméno počítače a jméno požadovaného dokumentu i s cestou -- označením adresáře, ve kterém dokument leží. Kompletní řetězec URI tak může vypadat např. následovně: http://www.mii.cz/home.htm. Dosti často bývá taktéž používáno označení URL (Universal Resource Locator), avšak dokument RFC 2068 (RFC je název souboru dokumentací Request For Comments, které je možno nalézt na celé řadě internetových serverů) popisující protokol HTTP 1.1 důsledně používá označení URI. Z tohoto důvodu je označení URI používáno i to tomto textu.

Dynamické generování dokumentů

HTML dokumenty spolu s vloženými obrázky bývají zpravidla uloženy na serveru v podobě souboru. URI osahuje identifikaci souboru (cestu v adresářovém stromu a jméno souboru), server soubor prostě přečte a odešle jej protokolem HTTP klientovi.

Služba WWW je ale mnohem mocnější, než je pouhé přenesení souboru na počítač klienta. Nic totiž nebrání serveru vygenerovat HTML dokument nebo obrázek definovaný URI dynamicky, v době zaslání požadavku klientem. Takový dokument pak může být jiný pro každého klienta, i když se na něj všichni odkazují stejným URI. Technika dynamického generování HTML stránek začíná být poměrně rozšířená u ekonomických informačních systémů hlavně z důvodu naprosté obecnosti a nezávislosti na software na straně klienta (k přístupu do takového systému stačí jakýkoliv WWW prohlížeč - a samozřejmě uživatelský účet a heslo). Všech těchto výhod lze samozřejmě využít i v oblasti průmyslových vizualizačních a řídicích systémů.

Omezení plynoucí z definice HTML

V rámci služby WWW je prakticky celá tíže prezentace dat ponechána na klientské části - WWW prohlížeči. Proto při návrhu aplikace můžete používat nejnovějších standardů a vlastností podporovaných prohlížečem, který budou používat vaši zákazníci. HTTP server nerozlišuje, jestli odesílaný HTML dokument je formátován podle nejstarších velmi jednoduchých specifikací HTML 2 nebo používá nejnovější vlastnosti definované v HTML 4, kaskádní styly, skripty apod. Je nutno si ale uvědomit, že čím novější a komplexnější formáty dokumentů jsou použity, tím více je zúženo množství klientských prohlížečů a taktéž platforem (operačních systémů) schopných tyto dokumenty korektně zobrazovat.

Za obrovskou univerzálnost a platformovou nezávislost prezentace dat prostřednictvím HTML se ale v každém případě platí cena v podobě relativně skromných možností ve srovnání s aplikacemi psanými pro určitou platformu (operační systém a počítač). HTML i HTTP vznikly jako projekt umožňující vědeckým pracovníkům sdílet textové dokumenty jen s velmi malými nároky na grafické zpracování. Při návrhu aplikace vizualizující data prostřednictvím HTML je tedy dobré mít na paměti omezení z toho plynoucí.

Služba WWW pracuje čistě na principu požadavek -- odpověď. Není možné, aby server sám poslal data klientovi např. při změně stavu nějaké veličiny, vzniku poruchy apod. Jediná možnost, jak zobrazit data v klientském prohlížeči je požádat o ně. Existuje způsob, jak pomocí meta značek přimět prohlížeč periodicky vyžadovat data. Pokud bude dokument obsahovat v rámci své hlavičky následující meta značku, bude prohlížeč periodicky žádat server o obnovu stránky v intervalu daném parametr "content":

  <head>
  < meta http-equiv="Refresh" content="5">
  <title>Periodicky načítaný dokument</title>
  </head>

Tento způsob ale nemusí pracovat ve všech prohlížečích, a pokud už pracuje, nemusí pracovat stejně v různých verzích prohlížečů nebo způsob obnovy nemusí být vyhovující. Např. Netscape Navigator reaguje tak, že sice opět přečte hlavní HTML dokument, ale již nepožádá o opětovné zaslání vnořených obrázků, čímž dokument zcela znehodnocuje. Poslední verze Internet Exploreru zase nedodržují pořadí načítání - nejprve hlavní dokument, poté jeho analýzou zjistit které obrázky dokument obsahuje a poté jejich načtení. Namísto toho IE 5 v předstihu požádá i o obrázky, které obsahoval předchozí dokument, čímž znemožňuje serveru dynamicky generovat obrázky v závislosti na odesílaném dokumentu. Proto je v případě použití této konstrukce vždy prověřit, jestli správně pracuje s WWW prohlížeči zákazníků.

HTML stránku zobrazenou v prohlížeči nelze obnovovat po částech. I pokud je zapotřebí měnit jedinou hodnotu, v principu musí klient znovu obnovit celou stranu. To vede k probliknutí celého dokumentu v prohlížeči. To samozřejmě není chyba serveru nebo WWW prohlížeče, ale omezení plynoucí z podstaty HTML a HTTP.

HTML má relativně omezené možnosti formátování. Většinou se dokumenty pružně přizpůsobují velikosti stránky prohlížeče. Stejné HTML konstrukce mohou v různých prohlížečích vypadat různě - zejména mezery před a po odstavcích, tabulkách apod. Některé HTML konstrukce mohou být daným prohlížečem interpretovány špatně či zcela pominuty. Nejprostší metodou jak vytvořit pevné formátování je použití HTML tabulek pevných velikostí. Pokročilejší technikou (a také mnohem obtížněji použitelnou) je použití kaskádních stylů CSS (Cascading Style Sheets). Zejména starší prohlížeče ale CSS vůbec nerozumí a i nejnovější prohlížeče s nimi mají problémy.

HTTP je bezstavový protokol. Pokud např. klient požádá o dokument, server mu jej odešle. Jestliže jsou v dokumentu odkazy na obrázky, klient o obrázky požádá server a ten je opět odešle. Z hlediska klienta se jedná o konstrukci jediného dokumentu, z hlediska serveru se ale jedná o samostatné a naprosto nezávislé dotazy. HTTP nedává prostředky, jak by server rozpoznal, že se jedná o dotazy jednoho klienta nebo o části jednoho dokumentu (ve skutečnosti takové prostředky existují, ale nejsou součástí HTTP, spíše se jedná o využití některých vedlejších efektů HTML). Server tedy neuchovává žádný stav spojení s daným klientem a jakýkoliv dotaz vyřizuje bez ohledu na předcházející nebo následující dotazy ať již od stejného klienta nebo z druhé strany zeměkoule.

Java

Veškerá omezení popsaná v předchozí podkapitole motivovala řadu vývojových týmů tato omezení překonat. Nakonec HTML je pouze popis formátu dokumentů a to v řadě případů nestačí - mnohdy je zapotřebí k dosažení žádaného efektu skutečně vykonat nějaký program. Ačkoliv pokusů spojit WWW s programováním bylo více, patrně nejrozšířenější je kombinace programovacího jazyka a virtuálního prostředí nazývaná Java firmy Sun Microsystems.

Prostředí Java je navrženo tak, aby bylo snadno přenositelné mezi různými operačními systémy. Protože klientské aplikace (WWW prohlížeče) jsou rozšířeny po celé řadě platforem a HTML je platformově nezávislá specifikace, snažili se autoři systému Java aby i programovací prostředí bylo stejně platformově nezávislé. Naneštěstí vytvořit přenositelný formát dokumentů je dramaticky jednodušší než vytvořit přenositelné programovací prostředí. Do pojmu Java se tedy skrývá více komponent:

• Programovací jazyk Java je čistě objektově-orientovaný jazyk se silným důrazem na bezpečnost vytvořeného kódu. Java se snaží pomocí omezení zavedených přímo do programovacího jazyka zabránit většině programátorských chyb. Např. v jazyku Java nelze přistupovat přímo k paměti počítače, lze jen vytvářet objekty a přistupovat na jejich data. Rovněž není možné vytvořit aplikaci, která by zapomínala vracet do systému nepotřebnou paměť, Java vrací paměť automaticky.

• Aby pracovaly programy psané v jazyku Java na více platformách, nejsou překládány do strojového kódu konkrétního procesoru, ale do univerzálního mezikódu zvaného byte-code. Původní představa autorů systému Java byla, že tento byte-code bude interpretován (vykonáván) dalším programem. Protože ale rychlost zpracování interpretovaného kódu je podstatně menší než přímo přeloženého programu (někdy až 100x), prakticky vždy je byte-code těsně před vykonáváním přeložen do kódu procesoru.

• Samotný program nikdy neobsahuje veškerou funkčnost ve svém kódu, vždy používá služby operačního systému. Programy psané v jazyku Java musí pracovat na všech platformách a proto ke své práci vyžadují virtuální prostředí, které se bude chovat stejně, i když bude pracovat pod různými operačními systémy. Toto prostředí se nazývá JVM (Java Virtual Machine). JVM zajišťuje zavedení byte-code představujícího program, jeho interpretaci nebo přeložení do strojového kódu daného procesoru a taktéž pro tento byte-code vytváří prostředí maskující specifické rysy skutečného operačního systému.

Firma Sun Microsystems propagovala systém Java jako malý, rychlý, efektivní, bezpečný, nenáročný na prostředky počítače (paměť a výkon procesoru), výkonný a přitom platformově nezávislý, pracující na většině existujících počítačů a operačních systémů. Systém s těmito vlastnostmi měl postupně nahradit vlastnické operační systémy a vytvořit novou platformu. Prakticky žádný z těchto cílů se ale nepodařilo splnit a tak nová platforma nevznikla. Příčin je několik:

• Java svou rychlostí nedokáže konkurovat aplikacím psaným v jiných jazycích. I když je byte-code přeložen a maximálně optimalizován pro konkrétní procesor, řada vlastností jazyka Java (např. automatické vracení nepoužívané paměti systému) brání dosažení rychlosti jiných aplikací.

• Java je podstatně náročnější na paměť a výkon procesoru, než jiné aplikace. Přes prohlášení firmy Sun bývá spotřeba paměti proti jiným aplikacím mnohonásobná.

• Aby Java pracovala na většině platforem, musí obsahovat jen nejmenší společnou množinu vlastností všech operačních systémů. Oproti vlastním službám operačních systémů jsou proto možnosti systému Java velmi omezené. Tato omezení se projevují v oblasti sítí a komunikací, grafiky a uživatelského rozhraní apod.

• Uživatelská zkušenost je u aplikací psaných v systému Java horší než u jiných aplikací. Aplikace v systému Java reagují velmi pomalu, překreslují se trhaně apod.

• Snaha o maximální zabezpečení je v protikladu k celkové flexibilitě systému. I když Java, stejně jako ostatní systémy, nezaručuje naprostou bezpečnost v síťovém prostředí, použití systému Java v rámci WWW prohlížeče přináší z bezpečnostních důvodů celou řadu omezení a vyžaduje pečlivé nastavení vlastností konkrétního prohlížeče.

• Java je stále vhodná jen na malé a jednoduché aplikace a stále více se používá na straně serverů, kde se její nedostatečný výkon projevuje jen na době odezvy a nezhoršuje uživatelskou zkušenost nekvalitním uživatelským rozhraním. Na straně klienta se většinou omezuje na jednoduché formuláře nebo panely.

• Java je prakticky omezena na jediný programovací jazyk. Tento jazyk je silně objektově orientován a jak známo, silná objektová orientace je obtížněji zvládnutelná než klasické procedurální metody programování. Tím se zúžuje potenciální množství programátorů schopných v systému Java psát programy. Navíc Java přináší z výše jmenovaných důvodů oproti jiným jazykům (např. C++) řadu omezení.

ActiveX OLE

Středem zájmu uživatelů produktů firmy Microsoft a tím pádem i jejich vývojářů byla po dlouhou dobu práce s dokumenty. Po integraci kancelářských aplikací do balíku Office vyvstala nutnost tvorby složených dokumentů, dokumentů obsahujících mimo formátovaný text i jiné datové typy, například tabulky a grafy tabulkového kalkulátoru. Zrodila se technologie OLE - Object Linking and Embedding (český překlad by snad mohl znít Vázání a zabudovávání objektů).

Původní verze OLE, dnes označovaná jako OLE 1, byla velmi neohrabaná, pomalá, nad možnostmi tehdy běžných kancelářských počítačů. Ke komunikaci mezi aplikacemi se používalo nepříliš efektivního protokolu DDE. Mezitím ve firmě Microsoft vznikla bázová technologie programových komponent, nazývaná COM - Component Object Model. COM ve své podstatě pouze definuje pojem softwarové komponenty a pojem binárního rozhraní komponenty, přístupné prostřednictvím tabulek funkcí. Taktéž definuje chování objektů jako např. jejich vznik, zánik a dynamickou detekci jejich rozhraní. Žádné další definice vlastností a chování jednotlivých komponent (i když je v názvu technologie COM použit termín objekt, z hlediska pojmů užívaných v objektově-orientovaných jazycích se o objekt nejedná, lépe by bylo hovořit o komponentě) nejsou v COM obsaženy. Na základě technologie COM byla postavena zcela nová verze OLE označovaná OLE 2. OLE 2 je natolik nová technologie, že s OLE 1 zbyl společný snad jen název.

OLE 2 umožňuje, aby na ploše jednoho kontejneru mohly existovat jednotlivé OLE dokumenty, tvořící výsledný dokument. Přičemž aplikace schopné pracovat s jednotlivými dokumenty mohou být ve zcela odlišných EXE souborech. Navíc OLE 2 umožňuje uživateli editovat vložené OLE dokumenty na ploše kontejneru, beze změny okna aplikace.

VBX

Zcela jiná vývojová skupina firmy Microsoft řešila problém, jako vyhovět řadě požadavků na rozšiřitelnost vývojového systému Visual Basic, který se mezitím stal pro svou jednoduchost a úspěšné skrývání komplexnosti vývoje aplikací pro Windows velmi polulární. Vznikl formát VBX (Visual Basic eXtension), umožňující psát vlastní komponenty, které pak bylo možno zabudovávat do formulářů aplikace Visual Basic.

Poněkud překvapivě trh s VBX komponentami velmi narostl a VBX se stalo nejživotaschopnější komponentovou technologií. Na rozdíl od objektově-orientovaných technologií VBX nekladly přílišné nároky na programátory a umožňovaly distribuovat komponenty v binární podobě, tedy bez zdrojového kódu.

Následoval logický krok překonávající řadu omezení VBX - spojení komponent systému Visual Basic a OLE dokumentů - tzv. OLE Controls, OCX. OCX plní stejnou úlohu jako VBX, ale mají řadu výhod. Především nejsou vázány na 16-ti bitové prostředí, ale pracují i ve 32-bitových Windows. Svou větší obecnost ale platí nárůstem složitosti.

Internet a Active X

Aby nějaká COM komponenta mohla být prohlášena za OCX, musí splňovat řadu podmínek, musí publikovat řadu rozhraní implementujících dosti složité chování. Tyto požadavky způsobují, že implementace OCX je složitá a DLL obsahující OCX jsou relativně velké.

Poté, co si firma Microsoft se značným zpožděním uvědomila význam Internetu, rozhodla se rozšířit technologii OCX tak, aby jednotlivé komponenty mohly být přenášeny po síti a zabudovávány do WWW prohlížeče. V praxi to znamenalo doplnění některých vlastností, jako např. možnost postupného zavádění obsahu po pomalé síti, ale především zrušení předpisů co všechno musí OCX obsahovat. Jedinou podmínkou zůstalo, že komponenta musí být schopna pracovat v kontextu procesu svého kontejneru. Komponenta tedy není povinna vyvážet vůbec žádné rozhraní s výjimkou základního COM rozhraní IUnknown. Technologie byla marketingovým oddělením pojmenována ActiveX, složené dokumenty se nazývají Active Documents a Internet Explorer, WWW prohlížeč firmy Microsoft, začal být schopen pracovat jako kontejner pro ActiveX komponenty.

Technologie ActiveX byla do značné míry postavena jako protiváha technologie Java firmy Sun Microsystems. Ovšem Java má oproti ActiveX řadu výhod i nevýhod:

• ActiveX je DLL knihovna obsahující rychlý binární kód, na rozdíl od mezikódu Java, který je na cílovém počítači interpretován nebo překládán těsně před spuštěním.

• ActiveX je možno psát v libovolném programovacím jazyce, Java je omezena jen na svůj programovací jazyk.

• ActiveX je platformově závislé, jedna komponenta může pracovat jen na počítači s daným procesorem a s daným operačním systémem (Windows) a daným prohlížečem. Java pracuje všude tam, kde pracuje její virtuální prostředí JVM, tedy na velkém množství počítačů a operačních systémů. Umístění ActiveX do HTML stránky tak vlastně omezuje potenciální uživatele, schopné stránku správně zobrazit.

• Protože ActiveX je plnohodnotný program, může provádět libovolné operace se soubory, na něž má právo přihlášený uživatel. Firma Microsoft proto zavedla digitální podpisy komponent, aby bylo možno odlišit důvěryhodné komponenty od případných pirátsky nastrčených komponent. Java má v sobě zabudovány bezpečnostní mechanismy zabraňující takovým manipulacím.

ActiveX tedy není internetovou technologií v pravém slova smyslu. HTML stránka s ActiveX komponentou totiž nepracuje na ničem jiném, než na počítači se systémem Windows a prohlížečem Internet Explorer. V prostředí Internetu se technologie ActiveX příliš nerozšířila, málokterá firma umístila na své stránky ActiveX komponenty. Mnohem většího rozšíření ale doznala v prostředí firemních intranetů s řízenou konfigurací klientů i serverů, kde lze zajistit, aby všichni klienti používali jeden operační systém a jeden WWW prohlížeč. ActiveX je tedy namísto Internetovou technologií spíše úspěšná komponentová technologie v prostředí Windows.

Rozvolnění specifikace ActiveX má ale i řadu nedostatků. Jestliže za ActiveX lze prohlásit prakticky libovolnou COM komponentu, je velmi obtížné vytvořit univerzální kontejner. Namísto vydání závazného dokumentu s jasnou definicí, co ActiveX komponenty a kontejnery umět musí, mají a mohou, jak je tomu prakticky u všech Internetových standardů popsaných v řadě dokumentů RFC, firma Microsoft vytvořila "referenční implementaci" v podobě knihoven MFC pro komponenty i kontejnery. Ovšem taková referenční implementace se vždy chová specificky a pokud se tvůrci ActiveX komponent spokojí s vyzkoušením své komponenty v prostředí MFC, neznamená to, že komponenta je bezchybná. Celá technologie ActiveX dnes pracuje dobře v prostředí vyvinutých zase firmou Microsoft, k dosažení robusnosti a obecnosti ale ještě musí ujít kus cesty.

Z hlediska obecného komponentováho návrhu má ActiveX ještě další nevýhodu v podobě dědictví OLE (většina názvů rozhraní ActiveX komponent stále začína předponou IOle...). OLE totiž bylo skutečně zamýšleno jako technologie složených dokumentů a proto se i u ActiveX komponent setkáváme s pojmy jako např. aktivace na místě apod., vhodnými skutečně spíše pro tabulku vloženou do textu než pro obecnou komponentu uživatelského rozhraní.

Distribuce průmyslových aplikací

Obrovský rozmach a všeobecná rozšířenost a dostupnost Internetu je jistě s výhodou využitelná pro řadu průmyslových aplikací. Aplikace řídící stroj na druhé straně planety může prostřednictvím Internetu technikovi poskytnout údaje nutné k odstranění závady a ušetřit tím nákladnou cestu a spoustu času, zodpovědný pracovník může kontrolovat běh technologie z libovolného počítače vybaveného WWW prohlížečem, např. ze svého bytu či z hotelového pokoje apod.

Proto je velmi výhodné, disponuje-li systém pro tvorbu průmyslových aplikací zabudovaným HTTP serverem. V řadě případů je k dispozici pouze přídavný modul, poskytující data pro nějaký jiný WWW server, např. Microsoft IIS nebo Apache. Problémem pak může být, pokud je zapotřebí provozovat aplikaci na počítači, který nedokáže daný server z prostorových nebo výkonnostních důvodů spustit, případně pokud je HTTP server vázán na konkrétní operační systém, např. na Windows NT Server.

Klíčová je těsná provázanost HTTP serveru se zbytkem systému. Prostřednictvím WWW prohlížeče musí být možné zobrazit jakákoliv data zpracovávaná aplikací a samozřejmě je výhodné, je-li možné prostřednictvím WWW prohlížeče data i modifikovat. V takovém případě je samozřejmě nutné zabezpečení celého systému proti neoprávněnému vniknutí.

Bohatost aplikace proti dosažitelnosti

Z hlediska rozprostření aplikace po síti jsou vždy v protikladu dvě tendence. První tendence je poskytnout uživateli co nejlepší zkušenost, tedy dát mu aplikaci maximálně využívající možností používaného operačního systému a vývojového prostředí. Druhá tendence je umožnit k aplikaci přístup z co nejširšího množství platforem, co nejméně uživatele omezovat ve výběru počítačů a jejich konfigurací, operačních systémů, WWW prohlížečů apod. V angličtině bývá tento konflikt označován „rich vs. reach“ – bohatost proti dosažitelnosti.

• Pokud je dán operační systém, z něhož budou zákazníci k aplikacím přistupovat, pak lze uživateli poskytnout veškerý komfort bez ohledu na rozprostření aplikací po síti. Je jen otázkou volby vybrat vývojový systém plně podporující modularitu nejen na lokální úrovni, ale i na úrovni více počítačů. Z hlediska síťového protokolu je dnes situace již zcela vyhraněná – TCP/IP je natolik rozšířený, že prakticky nemá konkurenci. Vlastnické protokoly mohou mít oproti TCP/IP mnoho nedostatků, např. nemusí být možné směrovat je v rámci složitých sítí či provozovat aplikaci prostřednictvím čistě internetových spojení. Pro aplikaci rozprostřenou na více počítačů je ještě velmi důležité jedno hledisko – jsou-li data po síti komunikována v reálném čase nebo jestli se jedná o pouhou synchrnonizaci dat s nedefinovatelnou a neřiditelnou dobou odezvy a reakcí jednotlivých prvků celého systému. To může být dostatečné pro nenáročnou vizualizaci, ale pro řízení strojů a náročnější aplikace je taková architektura nepoužitelná.

• Někdy je ale nutno zajistit přístup k aplikaci i z počítačů bez speciálně instalovaného software. Jediným dostatečně univerzálním klientem je prakticky pouze WWW prohlížeč. Pokud je ale prohlížeč používán jen jako kontejner pro ActiveX komponenty, jedná se prakticky o situaci z předchozího bodu, neboť jediným systémem schopným pracovat s takovou aplikací jsou Microsoft Windows 95/98 nebo NT. A i v případě použití Windows je nezbytné používat jediný WWW prohlížeč – Microsoft Internet Explorer. Jiné WWW prohlížeče, např. Netscape Navigator, s ActiveX komponentami pracovat nedokáže. Použití Java appletů již zpřístupní aplikaci velkému množství klientů. Java je podporována většinou WWW prohlížečů na většině operačních systémů, mimo Windows je tedy možné použít MacOS, různé varianty systémů UNIX a dokonce i systémy pracující na kapesních počítačích, např. EPOC32 populárních kapesních počítačů Psion 5 a Erricsson. S Javou to ale není až tak jednoduché. Nastavit všechny volby WWW prohlížeče tak, aby pracoval správně s applety komunikujícími po síti se vzdálenou aplikací není triviální. Síť zprostředkovávající komunikaci appletů musí poskytovat DNS služby, na uzavřených intranetech bez DNS Java neumožňujenavazovat spojení mezi applety a jinými počítači. Navíc stále lze narazit na nekompatibilitu implementací JVM v různých prohlížečích a operačních systémech.

• Naprostou jistotu zaručení přístupu k aplikaci téměř odkudkoliv představuje použití čistého HTML. I s použitím pouze HTML lze vytvořit kvalitní uživatelské rozhraní poskytující všechna potřebná data. A aplikace může být zpřístupněna i třeba i prostřednictvím televizního přijímače vybaveného jednoúčelovým WWW prohlížečem.