Chtěli bychom shrnout zkušenost, 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é.