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