Bohatost aplikace proti jejímu dosahu

Bohatost aplikace proti jejímu dosahu

Divák sledující v televizi agenta (stále častěji též agentku), který během několika sekund a pomocí několika úhozů na klávesnici (agenti zásadně nepoužívají myš) pronikne k databázi nějaké velké korporace nebo vládní či vojenské instituce, si zřejmě jen pomyslí, jak jsou počítače a počítačové sítě mocné a nebezpečné. Ovšem lidé, jejichž profesí je návrh, vývoj a údržba aplikací komunikujících s reálnou technologií nebo obecně poskytujících možnost přístupu k datům, si asi povzdechnou: „Kdyby to všechno šlo tak snadno!“ Vždyť jejich prací je umožnit svým zákazníkům právě takový přístup k datům, ať již uloženým v databázi nebo získaným v reálném čase z technologie či výrobního procesu. Narážejí při tom na množství problémů tkvících v nekompatibilitě různých výpočetních prostředí, v nestandardních formátech dat, v různých přenosových protokolech apod. (Jak to ti agenti dělají?)

Je možné tvořit aplikace přemosťující všechny tyto rozdíly? Klíčem by byla standardizace všeho, co je v různých systémech rozdílné – je ale taková standardizace možná? Odpověď je jednoduchá: něco skutečně může být standardizováno, ale standardizace kompletního výpočetního prostředí zřejmě možná není. Jednotlivé systémy se navzájem liší svým účelem a způsobem použití, pracují na různě výkonných procesorech a mají k dispozici různé množství paměti, jsou navrhovány pro různé skupiny zákazníků apod. Navíc jednotlivé firmy v konkurenčním prostředí musí intenzivně pracovat na dalším vývoji a každá nová vlastnost je vlastně porušením stávajícího standardu. Tyto rozdíly se s explozivním vývojem internetu a množstvím inteligentních zařízení se schopností komunikovat po síti spíše prohlubují než eliminují.

Změna paradigmatu

V době, kdy byla veškerá data uložena v centrálně spravovaném sálovém počítači a uživatelé usedali k textovým terminálům, se vše realizovalo pomocí aplikací psaných pro daný počítač a jeho operační systém a vše šlo poměrně hladce. Základním a jediným prostředkem komunikace uživatele s výpočetním systémem byl právě terminál. Pak přišly osobní počítače a přinesly svobodu rozhodovat, jaká data budou jednotliví uživatelé zpracovávat a jakými aplikacemi to budou dělat. Současně však přinesly problémy s přístupem k centralizovaným datům, se správou a správným nastavením jednotlivých počítačů apod. Souboj zcela centralizovaného zpracování s naprosto decentralizovaným zpracováním se ustaluje na střední cestě – některá data a aplikace je lépe umístit na centrální server a přistupovat k němu prostřednictvím počítačové sítě, jiné je lépe instalovat na lokální disk.

Naprosté rozmělnění výpočetních systémů a kombinace různých druhů zpracování dat (centralizované, lokální, smíšené) velmi pozměnily původně jednoduchý model aplikace běžící v centrálním počítači. Aplikace pracující v takovém prostředí musí brát v úvahu množství programových rozhraní všech systémů, s nimiž spolupracuje. Klíčem k rozmotání tohoto klubka se stala řada standardů pro sdílení dat mezi systémy. K databázím se přistupuje prostřednictvím jazyka SQL, data po sítích se přenášejí sadou protokolů TCP/IP, dokumenty se publikují ve formátu HTML apod. Svět výpočetní techniky tak neustále balancuje mezi standardizací, dovolující počítače rozumně využívat, a inovací, zajišťující další vývoj a pokrok.

Hledání standardu

HTML
Skutečný rozmach internetu nastal až po standardizaci jednotného formátu dokumentů v HTML (HyperText Markup Language) a protokolu přenosu těchto dokumentů HTTP (HyperText Transfer Protocol). HTML vznikl v evropských laboratořích jaderného výzkumu CERN jako formát pro publikaci a sdílení vědeckých informací. Protokol HTTP je velmi prostý a totéž lze říci o formátu HTML, alespoň v jeho základní podobě. Není proto příliš obtížné naprogramovat server, který poskytuje klientům dokumenty prostřednictvím HTTP. Dokumenty tak mohly být uloženy na libovolném počítači, pro nějž existuje server s možností poskytovat data v HTTP, a prohlíženy na jakémkoliv jiném počítači vybaveném programem rozumějícím formátu HTML.

HTML se tak stal široce uznávaným standardem pro sdílení informací. Samotný HTML má mnoho nedostatků, ale jako u všech standardů výhody plynoucí ze samotné standardizace nad těmito nevýhodami převažují. K problémům patří např. nejednotnost formátování – různé webové prohlížeče formátují stejný dokument v HTML různě. Rozdíly jsou ve velikosti i typu použitých fontů, v mezerách před a za odstavci a seznamy, ve formátování tabulek apod. Původní HTML ani nedisponoval prostředky pro přesnou specifikaci fontů, pozic obrázků, odsazování a mezer. Rovněž specifikace stránek v popisu HTML zcela chybí – dokument je formátován podle momentálních rozměrů okna prohlížeče a jeho vzhled např. po vytisknutí tiskárnou je značně nejistý.

CSS
S neustálým nárůstem významu HTML se samozřejmě objevila snaha již jmenované nedostatky odstraňovat. Začaly se objevovat stále novější verze specifikace HTML, do kterých přibývaly prostředky pro lepší specifikaci fontů, tabulek, rámců na stránce apod. Zásadním průlomem do formátovacích možností HTML bylo zavedení kaskádních stylů CSS (Cascading Style Sheets). S použitím stylů lze jednotlivé komponenty přesně umísťovat na stránce a manipulovat s nimi. S rozšířením možností HTML vybaveného CSS ale narostly i problémy se standardizací, původní idea prohlížení HTML na jakémkoliv prohlížeči se začala vytrácet, neboť zdaleka ne všechny prohlížeče CSS rozumí, a jestliže ano, není implementace vždy kompletní a navzájem kompatibilní. Použije-li autor dokumentu v HTML CSS, zmenšuje tím potenciální množinu uživatelů schopných dokument přečíst. Zde se začíná projevovat heslo použité v názvu tohoto článku – bohatost aplikace omezuje její dosah, čitelnost na co nejširší škále platforem.

Stále ale hovoříme o HTML jako o standardu formátování pro prezentaci dokumentů. Počítače ale data nejen prezentují, především s nimi manipulují. Platí tedy, že:

Data nestačí jen zobrazit, je nutné je i zpracovat

„Zrovnoprávnění“ výpočetních platforem používajících HTML a nezávislost na jediném výrobci byly pro mnoho firem velkou motivací pro vytvoření dalšího standardu unifikujícího nejen prezentaci, ale i zpracování dat. Tady je ale situace mnohem složitější než v oblasti prezentace. Ačkoliv HTML naprosto nestačí na specializované úkoly (např. tiskové předlohy novin a časopisů nelze v HTML vytvářet), je dostatečně dobrý na běžné sdílení informací čtených koneckonců převážně pouze v elektronické podobě na monitoru počítače. Bohužel dostatečně dobrý univerzální způsob zpracování dat se nalézt dosud nepodařilo a je otázka, zda je to vůbec možné. Ale popišme situaci popořadě.

Prvním krokem je zavedení skritptovacích jazyků do HTML. Přímo do dokumentu je možné zabudovat program ve skriptovacím jazyce (např. JavaScript nebo VBScript). Prohlížeč tento kód detekuje a interpretuje. Stránka v HTML tak může skutečně vykonávat kód a zpracovávat data. Tento způsob programování je nazýván skriptování na straně klienta, neboť server poskytující stránky s vloženými programy o těchto programech nic neví a ani se o ně nestará. Veškerá práce s programem je ponechána na klientovi.

Přenechání vykonávání programu na klientovi má ale podstatnou slabinu. Přes veškerou snahu o standardizaci existují v různých klientských programech rozdíly. Skript dobře pracující v jednom prohlížeči může v jiném prohlížeči pracovat chybně. Další prohlížeč nemusí se zvoleným skriptovacím jazykem pracovat vůbec, a protože skripty jsou nadstavbou HTML, existuje řada webových prohlížečů, které skriptování vůbec nepodporují.

Řešením je skriptování (programování) na straně serveru. Podstata je podobná – data zobrazená klientovi jsou pro něj zpracována, tj. nějakým programem je vytvořena jejich prezentace. Tentokrát však program nepracuje na klientském počítači, ale na serveru, a ke klientovi se dostane čistý kód HTML zobrazitelný jakýmkoliv webovým prohlížečem. Přesto je tento dokument unikátní, vytvořený dynamicky v okamžiku dotazu klienta a podle jeho požadavků.

Přenesením vykonávání kódu z klienta na server lze předejít problémům s kompatibilitou, prostředí na serveru je předem dané a autor aplikace může zajistit instalaci potřebných programů a aplikaci otestovat. Naproti tomu toto řešení s sebou nese nevýhodu v podobě zvýšené zátěže serveru, který musí zpracovávat data pro všechny klienty. Tato skutečnost se ale může obrátit k dobrému, jestliže data zpracovávaná aplikací musí být získána v reálném čase z technologie nebo přečtena z databáze. Pak má zpravidla serverová aplikace k datům mnohem blíže než klient – je připojena rychlou sítí, nebo databázový server dokonce běží na stejném počítači.

Nepochybně existuje velká skupina aplikací, v nichž tento model naprosto vyhovuje potřebám zákazníků. Příkladem mohou být jízdní řády – zákazníka zajímá informace o odjezdu vlaků či autobusů a odchylky formátování textu s nalezenými spoji v různých prohlížečích jsou pro něj nepodstatné. Naproti tomu ale stále existuje spousta aplikací, pro něž je tento model nepoužitelný. Aplikace vyžadující přesné formátování (textové editory, programy pro DTP), vysoký stupeň interaktivity (přímé řízení strojů, náročné rozhraní člověk-stroj, grafické editory, hry) a vysoký výkon (průmyslové řídicí systémy, tabulkové výpočty, simulace, vývojové nástroje) stále musí pracovat na lokálním počítači.

Java

Pokusem odpoutat všechny aplikace od lokálních počítačů, jejich procesorů a operačních systémů a zavést zcela přenositelnou programovou platformu proslul zejména jazyk Java firmy Sun Microsystems. Java měla být pro programový kód totéž, co byl HTML pro dokumenty. Ovšem programování je něco zcela jiného než zobrazování formátovaného textu a jazyk Java se zdaleka neujal tak, jak jeho proponenti očekávali.

Základním problémem je skutečnost, že má-li Java pracovat na všech systémech nehledě na typ procesoru nebo operačního systému, může podporovat jen nejmenší společnou podmnožinu funkcí těchto systémů. Každý operační systém má řadu vlastností, které jej činí unikátním a z nichž jeho aplikace těží maximum výkonu a pružnosti pro své uživatele. Aplikace psaná v jazyce Java je vždy o tyto výjimečné vlastnosti ochuzena a v podstatě nemůže nativním (tj. v daném prostředí původním) aplikacím konkurovat.

Další problém spojený s jazykem Java je nutnost práce jeho aplikací na různých platformách. Programy psané v jazyce Java proto nejsou překládány do strojového kódu konkrétního procesoru, ale do univerzálního formátu zvaného bytecode. Tento kód je jiným programem, zvaným JVM (Java Virtual Machine), již napsaným pro konkrétní platformu, vykonáván. Existuje množství JVM, z nichž některé bytecody interpretují instrukci po instrukci, jiné jej za běhu překládají do strojového kódu konkrétního procesoru. V každém případě tím ale více či méně utrpí rychlost a odezva aplikace. Připočte-li se k tomu ještě značná paměťová náročnost aplikací vytvořených v jazyce Java (což je v příkrém rozporu s hesly malý, rychlý, nenáročný a efektivní, kterých firma Sun ve své propagační kampani na podporu jazyka Java často užívá) a problémy s kompatibilitou jeho implementací, nelze se příliš divit, že se Java na straně klienta příliš neujala.

Active X

Zcela odlišným způsobem přistoupila k řešení problému programování aplikací pracujících v rámci webového prohlížeče firma Microsoft. Bez nároků na podporu více platforem rozšířila svůj komponentový standard postavený na technologiích OLE/COM o možnost dynamické instalace komponent prostřednictvím webu, rozšířila svůj webový prohlížeč o schopnost zabudovávat OLE komponenty a přejmenovala celou technologii na Active X. Protože komponenty vytvořené pomocí Active X jsou v podstatě binární moduly, stejně jako např. dynamicky linkované knihovny (DLL), mají kompletní přístup ke všem službám operačního systému a mohou využívat všechny jeho vymoženosti. Proto Active X komponenta může v prohlížeči pracovat maximálně efektivně, např. přehrávat video nebo realizovat náročné výpočty.

Naproti tomu je Active X standardem operačního systému Windows a nelze jej nazvat „internetovým standardem“ jako např. formát HTML. Nejenže stránka v HTML s Active X komponentami nebude pracovat na jiných platformách (UNIX/Linux, Apple Macintosh, BeOS apod.), ale nebude pracovat ani na PC se systémem Windows používajícím jiný webový prohlížeč, např. Netscape Navigator, Opera apod. Těchto platforem s rostoucím množstvím specializovaných přenosných zařízení a mobilních telefonů s možností přístupu k internetu s rozličnými systémy a prohlížeči stále přibývá. Active X komponenta vytvořená pro PC nebude fungovat ani na nových zařízeních pracujících se systémy Windows CE.

Jak již bylo uvedeno, Active X je v podstatě binární knihovna systému Windows, a proto může stránka obsahující jeho komponenty reagovat podobně jako jiné aplikace systému Windows (v podstatě jde o aplikaci Windows, přestože její komponenty jsou zabudovány do webového prohlížeče). Nabízejí-li výrobci aplikací a vizualizačních systémů postavených na Active X své aplikace jako systémy využívající pouze dokumenty v HTML, jde o klamavou reklamu. Je nutné mít na zřeteli, že na straně uživatelů musí být použit Internet Explorer v prostředí Windows jakožto jediný webový prohlížeč podporující Active X.

Komunikují-li javové applety i Active X komponenty ve stránce v HTML za běhu v rámci počítačové sítě (např. dotazují se databáze na data), přináší to ještě jeden problém. V prostředí sítě je totiž třeba chránit jednotlivé počítače před nechtěnými i úmyslnými útoky. Tato ochrana bývá svěřena speciálním programům nebo i celým počítačům nazývaným firewall (česky „protipožární stěna“), bránícím před neoprávněnými přístupy. Velmi často bývá v této stěně jen malá skulina dovolující přenos dat protokolem HTTP. Jestliže chce javový applet nebo Active X komponenta navázat síťové spojení, nemusí se mu to podařit, a instalace takové aplikace vyžaduje snížit stupeň zabezpečení celé sítě.

Čím je aplikace bohatší, tím menší okruh klientů ji může používat

HTML je v současné době snad jediný skutečně univerzálně rozšířený a dostupný formát dat. Naprosto největší dosah mají tedy aplikace poskytující klientům čistý kód HTML. Webové prohlížeče zobrazující HTML jsou k dispozici na velkém množství platforem a dostávají se i na některé mobilní telefony. Aplikace však musí fungovat na straně serveru. V aplikaci je taktéž omezena interaktivita uživatele (změna informací vyžaduje opětovné zavedení a „probliknutí“ celé stránky). Rovněž nelze spoléhat na shodné formátování stránky ve všech prohlížečích a na shodnou interpretaci všech formátovacích značek.

Jsou k dispozici i rozšíření HTML, která zahrnují skriptování, přesné formátování stránky (CSS) či kombinaci obojího (DHTML – Dynamic HTML). Aplikace využívající tyto možnosti mohou pracovat mnohem lépe (mohou být bohatší), ale nemohou počítat s tím, že všechny prohlížeče je dokážou správně interpretovat. Až nejnovější verze webových prohlížečů firem Microsoft a AOL (dříve Netscape) podporují CSS, ale přesto není implementace těchto standardů úplná a navzájem shodná. V implementaci skriptovacího jazyka JavaScript jsou rozdíly a jazyk VBScript podporuje jen firma Microsoft.

Další možností je využít applety (komponenty stránky HTML) napsané v jazyce Java. Takové applety mohou realizovat libovolné algoritmy (s již zmíněnými výhradami), ale klient za to platí vysokou náročností na výkon procesoru a množství paměti svého počítače. Javový applet k běhu vyžaduje JVM, a ten nebývá k dispozici ve všech prohlížečích. Zvláště v malých zařízeních není Java implementována nebo není kompletní. Javové applety připodobní stránku v HTML nativní aplikaci, ale platí za to dalším omezením platforem, na kterých mohou pracovat.

Cokoliv, co jen současná výpočetní technika dokáže, může realizovat nativní aplikace pracující v prostředí konkrétního operačního systému. I taková aplikace může komunikovat po síti, může být distribuována na více počítačů, ale je vázána na danou platformu – počítač a operační systém. Do této kategorie spadají i aplikace postavené na Active X, které využívají HTTP a služeb WWW v podstatě jen jako instalačního média. V principu lze stejnou aplikaci pracující jako skupina komponent vytvořených pomocí Active X vytvořit ve webovém prohlížeči nebo např. ve formuláři jazyka Visual Basic apod.

Při návrhu aplikace je tedy nutné vzít v úvahu okruh uživatelů a jimi používaných platforem, a to nejen v daném okamžiku, ale i s výhledem do budoucna, kdy se může svázanost s jedinou platformou ukázat jako vážný problém. Dále je nutné uvážit funkčnost aplikace, zdali jde o prostou vizualizaci několika hodnot nebo náročnou animaci či časově kritické řízení. Podle těchto požadavků je třeba vybrat programové nástroje k její realizaci.