kterou jsme učinili s technologií Java Web Start. Nasadili jsme ji v aplikaci Vklap, která slouží k podpoře sběru dat do
Informačního systému výzkumu a vývoje. Uživateli jsou
lidé z grantových agentur, ministerstev, univerzit,
Akademie věd, rozpočtových a příspěvkových organizací,
a víceméně všichni ostatní, kteří mají co činit s
výzkumem a vývojem podporovaným Českou republikou. Co
se úrovně znalosti práce s počítačem týče, jsou
uživatelé velmi různorodí.
Vklap je klasická swingová aplikace (vyžadující Javu
1.5), která slouží k editaci speciálních, lokálně
uložených souborů v XML. Aplikaci lze spouštět výhradně
pomocí technologie Java Web Start. Díky tomu je
distribuce nových verzí aplikace zcela transparentní.
Všechny jary jsou podepsané „plnokrevným“ certifikátem
pro podpis kódu, jinak bychom neměli přístup k souborům
na disku uživatele. Využíváme dokonce i asociaci
aplikace s příponou souborů (v našem případě „vav“) –
při poklepání se takový soubor otevře přímo v naší
aplikaci.
Měli uživatelé problém s instalací JRE?
Vzhledem k množství uživatelů bylo problémů tohoto
druhu minimálně. V některých organizacích může
instalaci softwaru provádět jen administrátor, ale pak
je spíše problém toho, kdy se k tomu dostane, než zda
to dokáže. Dali jsme na stránky aplikace též
ActiveX-ový prvek od Sunu, který umožňuje uživatelům
Internet Exploreru stáhnout JRE i spustit aplikaci
naráz.
Vyskytovaly se technické problémy?
Ano. Největším zdrojem problémů jsou proxy servery,
které se, zdá se, vyskytují snad v každé organizaci.
Vklap pro pár činností potřebuje komunikovat se
serverem: jednak potřebuje sám postovat soubor
protokolem https na server, jednak pro některé činnosti
potřebuje volat webservisy. Některé proxy servery
vstupovaly do komunikace přes https. Tím se však
šifrované spojení stává nedůvěryhodným, neboť klient
nemůže ověřit certifikát na straně serveru. Často však
bylo možné se správci sítě domluvit přímý přístup na
port 443 na těch dvou serverech, na které jsme
potřebovali přistupovat. Ani volání webservisů nebylo
bez problémů, ale většinou se to ve spolupráci se
správci sítí podařilo rozpohybovat.
Samotné JWS funguje poměrně dobře. Dokonce funguje i
off-line, aplikaci tak mohou uživatelé používat třeba
na notebooku ve vlaku. Všechny jary máme označované
verzemi, nespoléháme na timestampy. Jen občas se stává,
že se JWS vzbouří a z jakéhosi záhadného důvodu neověří
podpis u některých jarů, když se uživatel k aplikaci
vrátí po delší době. Když se provede vymazání cache JWS
a nové spuštění, je problém odstraněn.
Pro běh aplikace jsme doporučovali minimálně 256 MB
paměti v počítači, což většinou nebyl problém. Pravda,
pár dosluhujících počítačů bylo kvůli naší aplikaci
definitivně vyřazeno, ale to jejich uživatelé vítali. U
jednoho uživatele jsme aplikaci dokonce viděli úspěšně
se ploužit na počítači se 128 MB paměti – šlo to ztuha,
ale všechno fungovalo.
Jak na JWS reagovali uživatelé?
V zásadě s tím nebyly významnější problémy. Jakmile
nainstalovali JRE, prošli podle návodu několika okénky
a pak byli v aplikaci. A hlavní tahák, transparentní
aktualizace softwaru na počítači je v zásadě to, co
uživatelé už začínají očekávat.
Kdybyste si mohli znovu vybrat technologii, sáhli
byste opět JWS?
Ano.
Co byste na JWS navrhovali vylepšit?
JnlpDownloadServlet, který je k JDK přibalen, by měl
pečlivěji odměřovat své hlavičky, které ovlivňují
cachování. Zatímco verzované soubory .jar lze cachovat
zcela podle libosti, neboť by se neměly měnit, ty
malinké spouštěcí soubory JNLP by se cachovat neměly,
protože jinak se nerozpropaguje informace o nové verzi,
a taky se Vám na serveru nepovede udělat statistiku
spouštění.
Jo, a stahování JRE z www.java.com je pro některé
skupiny uživatelů trochu moc pouťové.