Atualização Automática

Processo de atualização automática é meio complicado e trabalhoso.
O ideal, já que existem muitas estações de trabalho é desenvolver um sistema web. Assim não será nescessário fazer atualizações em clientes

Você também pode dar uma estudada em applet. Um software java vindo da web (navegador) mas sedo executado na máquina do cliente. Talvez possa resolver seu problema

Applet é uma tecnologia ultrapassada que não deu muito certo, uma boa solução para atualizações automáticas de aplicações desktop é o Java Web Start:
http://www.java.com/pt_BR/download/faq/java_webstart.xml

Isso é verdade, ultrapassada sim

Mas o ideal mesmo seria um sistema web

Olá

Sim, é importante criar padrões. Mas se as aplicações que rodam na sua emprewsa foram feitas com VB, provavelmente não seguem nenhum padrão.

Padrões visuais de aplicações devem ser determinadas por especialistas em design gráfico. Gente que sabe qual distância deve ficar entre botões, qual o tamanho ideal de botão e principalmemente quais os tamanhos de tela do sistema (que dificilmente precisam ser mais do que 2)

Para possibilitar a equipe de desenvolvimento seguir os padrões, normalmente é preciso ditar e seguir uma regrinha bem simples:

Ninguém usará nenhuma ferramenta gráfica de criar telas e arrastar e colar componentes

Em outras palavras, depois que o designer gráfico definiu os padrões, estes devem ser seguidos a risca e para isto poder acontecer, não se pode permitir a criação automática de nada. Assim se evita ficar com sistemas com cara de VB com cada tela de um tamanho.

Se for uma aplicação Java do tipo swing usando Java Web Start, todos os requisitos de atualização serão atendidos. PORÉM só adote esta solução caso sua aplicação precise acessar periféricos do tipo impressora fiscal, leitor de cheque ou cartão, balança e demais coisas que são dificeis (mas não impossíveis) de serem acessadas em páginas web.

Caso contrário, desenvolva uma aplicação web cujo resultado será MUITO melhor.

Abraços
Luca

Olá

Os padrões a que me refiro não são visuais. Embora os softwares serem em VB, conseguimos criar alguns padrões de acesso ao banco com classes. Claro que a porcaria do VB não é orientado a objetos, mas ele possui algumas facilidades que nos permite criar um DAO, um VO entre outros =).

Como estamos engatinhando em desenvolvimento java para nossa necessidade, vamos montar primeiro todo o ambiente. Depois pensaremos em padrão visual, acesso ao banco (JPA, Hibernate, etc). Não conseguimos ainda criar aplicação web porque não possuímos um servidor Tomcat (está em negociação).

O nosso problema agora é em saber se vale a pena criar jar externo e acessar via URLClassLoader, ou se é melhor deixar uma pasta de componentes no classpath. Minha experiencia em URLClassLoader foi triste, porque eu consegui carregar o JAR externo, criei uma interface no aplicativo que carrega o JAR IDENTICA às assinaturas do componente mas o Java lançou erro de cast:

public class ComponenteFactory {

    private ClassLoader loader = null;
    
    public ComponenteFactory(){
        
        try{
            URL[] urlComponentes = {
                new File("D:\\Recursos\\BibliotecaDinamica.jar").toURL()
            };
        
            loader = new URLClassLoader(urlComponentes,  ComponenteFactory.class.getClassLoader());
        } catch  (Exception e){
            System.out.println(e.getMessage());
        }
        
            
    }    
    
    public Object get(String componente){
        
        if( componente.equals("Extra") ) return getExtra();
        return null;
       
    }
    
    private Object getExtra(){
        try{
            Class extra = loader.loadClass("Extra.Extra");
            
            for( Method m : extra.getDeclaredMethods() ){
                m.setAccessible(true);
            }
            Object objeto = extra.newInstance();
            //Method m = extra.getMethod("instanciar");
            
            //m.invoke(objeto, new Object[]{});
            return objeto;
        } catch( Exception e){
            System.out.println(e.getMessage());
        }
        return null;
    }
    
}

try{
            ComponenteFactory cf = new ComponenteFactory();
            extra = (Extra) cf.get("Extra");
        } catch( Exception e ){
            JOptionPane.showMessageDialog(null, e.getMessage());
        }
        extra.instanciar();
    }

Quanto a atualização, pensei em criar um aplicativo “Launcher” que ve se há moificação no JAR do aplicativo do servidor, troca o mesmo e o executa em seguida. Isso é válido?

Olá

Se você está começando, nada de pensar em ClassLoader. E use os padrões mais simples ou mesmo não use nenhum.
Design Patterns normalmente não devem ser usados por quem está começando. Primeiro a gente deve experimentar e só depois procurar saber se existe algo com mesmo jeitão que resolva de forma mais genérica.

Exemplo: VO.

Se seu VO é um Value Object, isto é, um objeto sem identidade conceitual (não é uma entity) que representa apenas um aspecto descritivo do domínio (descreve apenas coisas como cores, moedas, etc. que são atributos de uma entity) tal como define o Eric Evans no seu excelente livro Domain Driven Design então OK.

Mas se o que você entende como Value Object é um valor composto a partir do servidor com aquele modelo anêmico lotado de getters e setter que os “doutores” da Sun recomendavam e até cobravam em provas de certificação, então sugiro que jogue fora porque é pura poluição.

Abraços
Luca Bastos

Luca:

Olá

Se você está começando, nada de pensar em ClassLoader. E use os padrões mais simples ou mesmo não use nenhum.
Design Patterns normalmente não devem ser usados por quem está começando. Primeiro a gente deve experimentar e só depois procurar saber se existe algo com mesmo jeitão que resolva de forma mais genérica.

Exemplo: VO.

Se seu VO é um Value Object, isto é, um objeto sem identidade conceitual (não é uma entity) que representa apenas um aspecto descritivo do domínio (descreve apenas coisas como cores, moedas, etc. que são atributos de uma entity) tal como define o Eric Evans no seu excelente livro Domain Driven Design então OK.

Mas se o que você entende como Value Object é um valor composto a partir do servidor com aquele modelo anêmico lotado de getters e setter que os “doutores” da Sun recomendavam e até cobravam em provas de certificação, então sugiro que jogue fora porque é pura poluição.

Abraços
Luca Bastos

Usamos o VO no VB para representar uma tupla do banco. Usamos o DAO para executar o CRUD (do mesmo jeito que aprendi a uns tempos atrás na Caelum rs).

Acabamos saindo um pouco do que eu preciso entender. Mesmo que o ClassLoader seja complicado, se for a melhor solução, pode apostar que vou estudá-lo muito bem antes de começar a usar. Quero montar uma arquitetura onde os meus softwares sejam capazes de carregar os recursos compartilhados sem que eles fiquem presos. Por exemplo, se eu tenho 50 máquinas com 3 softwares diferentes e utilizando os componentes compartilhados, mas surgiu uma modificação de um desses componentes de última hora. Eu quero poder atualizar o recurso sem que seja necessário derrubar os 50 softwares abertos. Não importa que o recurso dos 50 fique desatualizado enquanto estiverem utilizando aquela instancia do aplicativo, mas quando eles fecharem a instância e abrirem outra, o aplicativo deve obter o recurso atualizado.

E ainda, a idéia de um aplicativo launcher para trocar o jar do software se houver atualização é legal?

Olá

Nada sei dos VOs do VB. Se são iguais aos da Sun, então são puro lixo em 99,999% das vezes.

Faça uma aplicação web… resolve todos os seus problemas e caso precise acessar algum periférico crie uma applet com este intuito.

Fuja de Swing e todas as demais complicações. E se mesmo assim ainda insiste em usar Swing, como já escrevi, não use o Netbeans para desenhar telas. Escreva os códigos dos componentes tal como os padrões definidos pelo designer gráfico e inclua no CÓDIGO (nunca na tela do Netbeans)

Abraços
Luca Bastos