Alguem já desenvolveu uma aplicação Desktop e Web

Olá

Ao invés de um servidor RMI, eu usaria um servlet container e enviaria as mensagens por http na porta 80. Assim minha aplicação poderia rodar sem problemas em qualquer tipo de rede e já obteria a tal integração que vc falou.

De resto sem problemas.

[]s
Luca

Blz Luca

Essa era uma das opções, mas como o operador irá tratar algumas vezes mais de 5.000 eventos eu achei que poderiamos ter um grande problema de performance.

Nesse caso eu trafegaria esses eventos também pelo HTTP? Ou conectaria o operador diretamento no Repositório de eventos?

Grato pelo auxílio.

Juliano Lao

Olá

O que é o servidor RMI além de intermediar as mensagens? O mesmo que seria o seu servlet. Tudo o mais fica igual tanto em um caso como no outro.

Quanto ao problema de número de eventos simultâneos acho que o servidor RMI de referência vai abrir o bico antes do que o Tomcat&assemelhados. E com o Tomcat&assemelhados, vc pode passar apenas dados ao invés dos objetos completos.

[]s
Luca

Luca, bem visto.

Grato pela opinião, vou fazer alguns testes por aqui.

[]s

Juliano Lao

Olá

Alguém não gostou. Opiniões em contrário são bem vindas. Aguardo-as.

[]s
Luca

A sugestão do Luca é boa e creio ser bem mais performática que RMI.
Mas acho que vale analisar e avaliar o uso de Web Services, não?
Pois o trabalho de se trabalhar com o protocolo HTTP será maior do que usar simplesmente WS.

Olá

Sim, concordo que WS são bem mais fáceis de programar e manter.

Mas se as mensagens são somente dados, o melhor desempenho pode favorecer a solução simples com URLConnection + HttpClient.

[]s
Luca

WebServices sao, mesmo, tao mais faceis de programar e manter do que um clientezinho HTTP simples e um servlet que devolve um XMLzinho com os dados, tipo o del.icio.us?

Dada a economia de banda, processamento e recursos em geral, eu nao vejo mtos motivos pra se usar WebServices, especialmente nao nesse caso.

Olá

Concordei que WS é mais fácil apenas porque WS é mais genérico. Na verdade sou suspeito para falar porque sou um pouco inimigo de WS em casos simples pois já vivenciei este problema. Imagine que os caras usaram SOAP para fazer Java falar com Java. E para enviar dados de cartão de crédito que é uma área em que se precisa de muita performance.

[]s
Luca

Galera, interessantes considerações.

Quando a WS, nós vamos utilizar para o recebimento dos arquivos (juntamente com FTP) para processamento em lote deles.

Isso será feito pois muitos clientes desse cliente não “gostariam” de enviar os dados por FTP e como o sistemas deles são em ambiente Microsoft achamos melhor resolver assim. Já realizamos alguns testes usando o WS e esses clientes e até agora está tudo perfeito.

Quanto a operação, eu nunca precisei integrar Swing com HTTP. Eu tenho uma aplicação de workflow (possui algo em torno de 35.000 processos na memória do servidor) e todos os clientes são em Swing e o servidor em RMI. Nesse caso eu pego as instancias dos objetos de dados diretamente do servidor, habilito o callback para notificação, crio os modelos para o Swing e acabou o meu problema. Nesse caso como ficaria fazer essa interface através de HTTP?

Grato a todos

[]s Juliano Lao

Vê se esse script te ajuda.

MySwing.java

public class MySwing {

    /**
     * 
     */
    public MySwing() {
        super();

    }

    public static void main(String[] args) {
        
        try { 
        
	        String urlServlet = "http://127.0.0.1:1977/swingServlet/MyServlet";
	        
	        URLConnection urlConn = null;
	        
	        URL url = new URL(urlServlet);
	        

	        urlConn = url.openConnection();
	        
	        urlConn.setDoInput(true);
	        
	        urlConn.setDoOutput(true);
	        
	        urlConn.setUseCaches(false);
	        
	        urlConn.setDefaultUseCaches(false);
	        
	        urlConn.setRequestProperty("content-type", "application/octet-stream");
	        
	        Bean1 bean1 = new Bean1();
	        bean1.setIdade(new Integer(21));
	        bean1.setNome("Rodrigo");
	        
	        ObjectOutputStream objectOutputStream = new ObjectOutputStream(urlConn.getOutputStream());
	        
	        objectOutputStream.writeObject(bean1);
	        
	        objectOutputStream.flush();
	        
	        objectOutputStream.close();
	        
	        BufferedReader in = new BufferedReader(new InputStreamReader(urlConn.getInputStream()));
	        
	        Object objectReceive = null;
	        
	        ObjectInputStream objectInputStream = new ObjectInputStream(urlConn.getInputStream());
	        
	        objectReceive = objectInputStream.readObject();
	        
	        objectInputStream.close();
	        
	        Bean1 beanOuput = (Bean1) objectReceive;
	        
	        System.out.println(beanOuput.getNome()+"\n"+beanOuput.getIdade());

	        
    	} catch(Exception e) {
    	    
    	    e.printStackTrace();
    	    
    	}
        
    }
    
}

MyServlet.java

public class MyServlet extends HttpServlet {

    /**
     * 
     */
    public MyServlet() {
        super();

    }
    
    /* (non-Javadoc)
     * @see javax.servlet.http.HttpServlet#service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
     */
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

        try {
        
	        ObjectInputStream objectInputStream = new ObjectInputStream(request.getInputStream());
	        
	        Bean1 bean1 = (Bean1) objectInputStream.readObject();
	        
	        objectInputStream.close();
	        
	        ObjectOutputStream objectOutputStream = new ObjectOutputStream(response.getOutputStream());
	        
	        Bean1 bean12 = new Bean1();
	        bean12.setIdade(bean1.getIdade());
	        bean12.setNome(bean1.getNome());
	        
	        objectOutputStream.writeObject(bean12);
	        
	        objectOutputStream.flush();
	        
	        objectOutputStream.close();
        
        } catch(Exception e) {
            
            e.printStackTrace();
            
        }
        
    }

}

Bean1.java

public class Bean1 implements Serializable{

    private String nome;
    private Integer idade;
    
    
    public Integer getIdade() {
        return idade;
    }
    
    public void setIdade(Integer idade) {
        this.idade = idade;
    }
    
    public String getNome() {
        return nome;
    }
    
    public void setNome(String nome) {
        this.nome = nome;
    }

}

Lógico no exemplo da Classe Swing não é um Swing e sim uma classe normal com o método main(mas serve como se fosse um Swing).

Sem mais, Rodrigo.

Valeu pelos exemplos

[]s

Chulao:

Valeu pelos exemplos
[]s

Jóia!

Aqui na empresa iremos desenvolver tanb uma aplicação desktop com Web…

Sem mais, Rodrigo.

Se eu fosse você, usaria Apache Commons HttpClient.

Olá .
Estou acompanhando o tópico de vocês e aprendendo muito no guj em geral

Vou começar minha primeira aplicação java comercial, desktop + web. Se bem que esse " + web " no meu caso deva ser uma coisa mais simples, mas só pra eu entender :

Esses exemplos abaixo e mais a dica do daniel seriam para serializar objetos em um servidor web ?

O que minha aplicação local terá que fazer é apenas acessar o banco de dados no servidor web. Além de acessar o banco de dados ( mysql ) pela sua respectiva porta, através do conector sql do java rodando dentro da aplicação local quais outras possíveis maneiras me recomendariam?

[ ]
Adriano

Olá

Não, isto seria VeBelizar o Java…(arghhh…)

Você deve escrever sua aplicação como se ela fosse completamente separada em camadas ou partes estanques.

A parte que roda no desktop é a camada de apresentação e deve apenas capturar e validar os dados. Estes devem ser passados ao servidor e isto pode ser feito de várias formas: serialização, xml puro, txt, etc.

A camada do servidor funciona como um intermediário. Sua única função é receber e enviar mensagens, traduzir protocolos, sequenciar mensagens e cuidar dos estados. O servidor pode se comunicar com outra camada que cuida das regras de negócio. É esta camada que acessa ao banco de dados.

Para mim a camada servidora SEMPRE deve trabalhar com mensagens via http pois assim não temos problemas com administradores de rede que normalmente bloqueiam protocolos estranhos.

[]s
Luca

Concordo com você Luca, no aspecto de separar o sistema em camadas, seria mesmo o ideal. Mas concidere as seguintes peculiaridades do meu caso :

Me foi pedido o desenvolvimento de um sistema especifico, mas quero levar a coisa de uma maneira para que possa com esse trabalho criar uma ferramenta mais poderosa e flexível, para comercializa-la depois.

No momento, meu cliente não tem um servidor web próprio, e mesmo a porcaria do vb ( no meu caso pra dar exemplo simplista falaria no clipper , porque do vb odeio até o nome :mrgreen: ) atenderia-o bem. E ele não exigiu nenhuma linguagem específica, a propósito.

Quero aproveitar a oportunidade de desenvolvendo o sistema para o cliente, aprimorar meus conhecimentos em java.

É uma aplicação desktop, rodando em uma rede (interna ) com 10
usuários.

A única coisa que ele deseja é acessar os dados de qualquer lugar, quando necessário. Pensei até no caso de disponibilizar apenas alguns relatórios em html estáticos mesmo, gerado pela aplicação.

Pelo volume de dados que ele vai lidar, não posso deixar que meu sistema pareça ( aos olhos dele ) excessivamente pesado. Por exemplo, instalar tomcat na rede dele e disponibiliza-la para o mundo, por
exemplo

Anteriormente desenvolvi uma aplicação desktop para rede local usando swing+hsqldb , e quase não percebi perda de performance no acesso aos dados, além de todas as demais vantagens de usar um servidor de banco de dados. Sei que assim dá pra fazer, mas quero dar um passo à frente, sem que haja perda de qualidade no produto final.

O que já assimilei disso tudo :
:idea: Vou dividir o sistema em camadas de qualquer maneira, mesmo que rodando somente na rede local.
:idea: Vou usar o hybernate, para depois facilmente poder trocar de banco de dados, conforme o caso.
:idea: http sempre que possível para comunicação com servidores externos.

E todas as dicas para esse meu início de trabalho dos feras do guj, serão muito bem vindas, claro

[ ]
Adriano

Olá

Faça do jeito que falei mesmo se vai rodar tudo na mesma máquina. Se amanhã resolver colocar o tomcat em outra máquina já está tudo pronto.

Mas principalmente faça SÓ o que o cliente quer. Nunca faça nada a mais só com o intuito de aprender a tecnologia. Você não vai cumprir os prazos e queimar seu filme.

[]s
Luca

Eu sei, me seguro direto pra não fazer um “elefante branco”

Como a interface que vou usar será o swing, não vou nem instalar o tomcat, por hora. Apenas Jre nos clientes da rede mesmo.

Já pensou em ter os clientes assinando a tópicos JMS diretamente? Me parece mais simples que ficar com toda essa enrolação com HTTP/RMI.

Olá

Louds, já viu alguém rodar JMS em rede local para fazer CRUD?

[]s
Luca

Luca:

Olá

Louds, já viu alguém rodar JMS em rede local para fazer CRUD?

[]s
Luca

Devo ter entendido errado oque ele queria, mas a questão toda não é os clientes pegarem as notificações de eventos que chegam no servidor? Para todas operações CRUD não, mas as que modificam estado já vi algumas que fazem sim.

Por sinal é uma boa forma de integrar web e desktop, ambas postam mensagens na mesma fila.

Olá

Louds, sou enorme fã de JMS e achei boa a sua lembrança. Mas nem sempre se pode usar para integrar desktop com servidor. Usando http é possível fazer a interface do usuário com swing, thinlet, SWT (como seria o caso de JMS) mas também com html.

Aliás, fugindo totalmente do foco da pergunta inicial, aproveito este gancho para reafirmar o que disse para alguns durante o JustJava: na minha máquina o Firefox e o Internet Explorer são aplicações que rodam a partir do desktop. Então eu não vejo diferenças entre aplicação desktop e aplicação web. Para mim todas as aplicações devem ser web pois não vejo nenhum sentido em desenvolver aplicações stand-alone e a única diferença é se a interface é html ou interface gráfica.

[]s
Luca

Só um detalhezinho inútil: trocar mensagens XML via http sem usar SOAP é WebService sim.

REST