Usando o Java Web Start

O Java Web Start é uma ferramenta criada pela Sun para facilitar a instalação de aplicações sobre a Internet. De forma bastante sucinta, é possível através de uma URL baixar o arquivo de configuração/definição (.jnlp) e carregá-lo com o Java Web Start local ($ javaws -viewer), que faz o trabalho de checar a versão da aplicação, especificidades que o desenvolvedor planejou para seu programa, download, instalação e execução.

Toda aplicação carregada pelo Java Web Start roda dentro de uma sandbox, um conceito bem parecido com os applets para implementar segurança para o cliente, que afinal, está rodando uma aplicação baixada via Internet. O JWS dá mais flexibilidade ao desenvolvedor, que pode acessar recursos locais através de Services APIs, que tem classes como FileOpenService, para manipular arquivos.

Neste artigo iremos, iniciar com uma aplicação simples (JFrame) que salva texto escrito pelo usuário em arquivos locais, levá-la para o Java Web Start e assiná-la, para que a JVM execute-a fora do sandbox. A aplicação foi criada acessando diretamente o sistema de arquivos, e precisaria ser alterada para usar as Services APIs. Como não queremos alterar a aplicação, a executaremos fora do sandbox através da assinatura com certificados digitais e o JWS pedirá permissão ao usuário para executá-la. O ponto chave aqui é instalar e executar aplicações Java através do contexto do navegador, para possibilitar integração com uma aplicação web.

Primeiro o aplicativo. Ele é um editor de texto simples. Na verdade ele só cria texto. Possui apenas uma JTextArea em que o usuário pode digitar e um menu com a opção de salvar o conteúdo do JTextArea em um arquivo de texto, cujo nome será fornecido pelo usuário. Você pode baixar os fontes dele (na forma de um projeto para o NetBeans) e o aplicativo já empacotado e compilado.

Uma vez com baixado o arquivo empacotado, descompacte-o e execute com o comando:

$ java -jar EditorDeTexto.jar

Faça um teste no programa para ver como ele funciona. Na etapa de salvar o arquivo, o programa pergunta o nome dele. Neste momento se somente o nome e extensão forem passados, o arquivo será criado no diretório que o aplicativo foi executado. O ideal aqui é passar um caminho completo, para testarmos e compararmos com o JWS. Depois de salvar o arquivo basta fechar o programa.

Agora vamos expor sua instalação através do Java Web Start. Para isso basta criarmos um arquivo com extensão .jnlp e escrever nossas especificações para que o JWS do cliente local leia e as utilize. Um primeiro arquivo de exemplo poderia ser esse (editor.jnlp):

<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://localhost/~lius/" href="editor.jnlp">
    <information>
        <title>Editor de Texto</title>
        <vendor>Hypercast</vendor>
        <homepage href="http://hypercast.info/"/>
    </information>
    <resources>
        <j2se version="1.5+"/>
        <jar href="EditorDeTexto.jar"/>
        <jar href="lib/appframework-1.0.3.jar"/>
        <jar href="lib/swing-worker-1.1.jar"/>
    </resources>
    <application-desc main-class="editordetexto.EditorDeTextoApp"/>
</jnlp>

Veja que este é um arquivo baseado em XML e está muito simples. O JWS permite muito que passemos parâmetros muito mais específicos par a JVM do cliente, mas esse já está bom para começar.

As parte mais importantes deste arquivo são os resources, onde você deve incluir todas as bibliotecas que precisar, indicando o caminho delas dentro do servidor web. Veja que mantive a estrutura idêntica ao que tinha anteriormente, mesmo quando a aplicação já estava feita e funcionando. Basta copiar toda a estrutura para um diretório exposto no servidor web e criar esse arquivo jnlp e colocá-lo junto, no mesmo nível. Dê uma olhada na função dos outros parâmetros na documentação do JWS, mas de qualquer forma eles são bem auto-explicativos.

Acesse via navegador a URL com o arquivo jnlp. Caso sua JVM/JRE estiver corretamente instalada, com os plugins para os navegadores que você tem na máquina local, o JWS já irá reconhecer a extensão do arquivo e carregá-lo imediatamente. Senão, verifique suas configurações locais. Você pode ainda configurar o servidor web para, quando for fornecer um arquivo .jnlp, alterar o MIME type para uma aplicação Java Web Start, facilitando o trabalho do navegador.

Veja que a instalação é muito simples. Teste a aplicação e vai ver que ela não funciona direito. Logo após informar o nome do arquivo para que o arquivo seja salvo, a aplicação é fechada. Isso ocorre devido a um erro que ocorre na forma de uma exceção de segurança na JVM, pois nesse caso tentamos criar um arquivo diretamente, mesmo rodando dentro da sandbox.

Agora iremos assinar os arquivos .jar da aplicação e informar para o JWS que a aplicação precisa rodar fora do sandbox, através de uma entrada no arquivo editor.jnlp. Para assinar, você precisará de certificados digitais que assegurem que você é quem diz ser, fornecidos por empresas especializadas no ramo e confiáveis, como VeriSign e Thawtee. Em ambiente de desenvolvimento, você pode usar ferramentas como o keytool, que é fornecida junto com o JDK. Iremos utilizá-la para criar chaves assinadas e prontas para usar, como se nós fossemos uma entidade certificadora. Rode o comando:

$ keytool -genkey -keystore mykeystore -alias mykey

Esse comando gera uma nova chave chamada mykey e a armazena um arquivo de chaves chamado mykeystore, que é criado no mesmo diretório em que o keytool foi executado. Uma vez com a chave pronta, só falta assinar os arquivo .jar, com o comando:

$ jarsigner -keystore key/mykeystore EditorDeTexto.jar mykey

$ jarsigner -keystore key/mykeystore lib/appframework-1.0.3.jar mykey

$ jarsigner -keystore key/mykeystore lib/swing-worker-1.1.jar mykey

Cada um desses comando irá abrir o arquivo que contém as chaves (mykeystore) e utilizar a chave mykey para assinar o arquivo .jar passado como parâmetro. Todos eles precisam ser assinados. Para saber mais opções sobre o keytool, veja sua manpage. Agora falta alterar o arquivo editor.jnlp para solicitar execução sem restrições ao JWS. O novo arquivo fica assim (diferenças em negrito):

<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://localhost/~lius/" href="editor.jnlp">
    <information>
        <title>Editor de Texto</title>
        <vendor>Hypercast</vendor>
        <homepage href="http://hypercast.info/"/>
    </information>
    <resources>
    <j2se version="1.5+"/>
        <jar href="EditorDeTexto.jar"/>
        <jar href="lib/appframework-1.0.3.jar"/>
        <jar href="lib/swing-worker-1.1.jar"/>
    </resources>
    <application-desc main-class="editordetexto.EditorDeTextoApp"/>
    <security>
        <all-permissions/>
    </security>
</jnlp>

Acesse a URL do editor.jnlp novamente e veja que dessa vemos temos que confirmar que queremos instalar a aplicação, em uma janela feia que diz que nossa aplicação não é confiável, por não ser assinada por uma entidade certificadora conhecida. Agora basta criar um arquivo e salvá-lo em seu sistema de arquivos, utilizando um caminho completo (no meu caso, usei /home/lius/arquivo.txt) e verá que o arquivo foi corretamente criado.

Algumas considerações finais:

• Se tiver muitos arquivos para serem assinados, crie uma tarefa para o Ant e automatize o processo;
• Veja os parâmetros do comando keytool para flexibilizar mais a criação das chaves e certificados. Os parâmetros que usei nos comandos foram mínimos para a aplicação rodar, mas para colocar em produção, por exemplo, seria bom que a validade da chave fosse prolongada;
• Ao colocar a aplicação em produção, seria o ideal que uma entidade de certificação fosse criada pelos desenvolvedores da aplicação, com ferramentas específicas para esse fim, como o toolkit OpenSSL;
• Os testes deste artigo foram feito com Debian Etch, Apache2, Iceweasel e JDK 1.5, tudo instalados a partir dos pacotes da distribuição.

Espero que o artigo tenha sido útil, e aproveitando a oportunidade, vou prometer um artigo sobre certificação digital, que está faltando realmente aqui no Hypercast. Até mais!

Artigos Relacionados:

• Apresentação sobre Java Web Start
• Palestra Fisl 9.0: Mozilla XULRunner - Utilizando XUL, Javascript e SQLite para aplicações desktop
• Palestra Fisl 9.0: Enabling Real-time RIA with Apache Derby and Comet
• Palestra Fisl 9.0: RT Linux e RT Java - Um novo mundo sem delays
• Palestra: Memory Leaks in Java Applications
• Configurando o WebAPSEE Server para acesso remoto e as estações de trabalho