Sistema cliente/servidor para desktop

Galera é o seguinte: pesquisando sobre esse assunto, encontramos diversas respostas, o que parecem ser alternativas para essa implementação. Vimos que podemos utilizar o RMI, Socket ou até mesmo criar um atalho do jar que está no servidor para os clientes(nesse caso na conexão com o banco se especifica ao invés de localhost, o endereço ip do servidor ou seu nome). Gostaríamos da opnião de vcs. Se possível um exemplo de um programa bem simples, para vermos a implementação. Nossa intenção é desenvolver um sistema desktop cliente/servidor, na qual o servidor vai ficar como o SGBD instalado e no cliente só a interface. Outra dúvida é como seria essa implementação com respeito aocliente e ao servidor. Teríamos de criar dois sistemas diferentes, um acessando o banco(servidor) e outro fazendo as solicitações(cliente) para o servidor(como consultas, cadastros, etc) ?
Desde já agradecemos a atenção.

E por que tem que ser desktop?

De início, pelo conhecimento que temos, faz-nos desenvolver para desktop, futuramente quando tivermos um conhecimento para web, poderemos fazer, mas agora é uma opção nossa desenvolver para desktop.

É que se você não sabe já fazer a comunicação, você terá que estudar tanto ou mais para fazer uma boa aplicação desktop remota, do que teria que fazer com web. Sendo que para a última, vocês já usariam uma tecnologia bem mais comum, adotariam uma tendência forte de mercado e abririam para si um leque de tecnologias extremamente úteis que não dominam ainda.

Você pode realmente usar RMI, mas além de não ser uma opção comum, há menos documentação e menos gente a adotando. Menos frameworks prontos, menos problemas conhecidos, menos suporte por parte dos colegas do guj…

O mais simples possível, seria você ter apenas o servidor de BD remoto. Os drivers de bancos como o MySQL já fazem a conexão sozinhos. Entretanto, você precisará otimizar queries, para que existam o menor número de consultas ao banco possível. É melhor uma única query gigantes, do que várias queries menores, já que a latência aumenta terrivelmente.

Não seria interessante criar atalhos do jar do servidor para as estações? E na conexão com o banco colocarmos o ip do servidor ao invés de localhost?

Cada estação terá sua própria versão do software. Claro que lá você deixa o endereço do servidor. E terá que ser um endereço público, num servidor público.

Uma solução que pode ser interessante é deixar também a aplicação toda no servidor, e dispara-la na máquina do cliente via jnlp. É o que eu faço no particles. Essa abordagem tem várias vantagens:

  1. Fica fácil de fazer updates no aplicativo (você só faz no servidor);
  2. Vocês podem continuar programando com o banco em localhost;
  3. Vocês não expõe o seu banco de dados na internet;

A desvantagem é que o cliente terá que aturar o tempo de download da aplicação. Ele nem sempre é tão rápido quanto ele gostaria.
A aplicação pode inclusive ser em tela cheia, como é o caso deste exemplo.

Cada estação terá sua própria versão do software. Claro que lá você deixa o endereço do servidor. E terá que ser um endereço público, num servidor público.

Uma solução que pode ser interessante é deixar também a aplicação toda no servidor, e dispara-la na máquina do cliente via jnlp. É o que eu faço no particles. Essa abordagem tem várias vantagens:

  1. Fica fácil de fazer updates no aplicativo (você só faz no servidor);
  2. Vocês podem continuar programando com o banco em localhost;
  3. Vocês não expõe o seu banco de dados na internet;

A desvantagem é que o cliente terá que aturar o tempo de download da aplicação. Ele nem sempre é tão rápido quanto ele gostaria.
A aplicação pode inclusive ser em tela cheia, como é o caso deste exemplo.[/quote]

Olá, o ViniGodoy tem razão, no caso de ser uma app Desktop o melhor mesmo e usar o Java Web Start (JNLP), e vc pode dividir a sua aplicação em varios arquivos .jar, com isso o download do sistema pode ser de um tempo menor caso você atualize somente parte deles. Outro ponto importante e fazer o uso de boas praticas para o desenvolvimento, views e procedures para o db que ajudam na velocidade de carga dos dados na hora da recuperação dos mesmos.

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html
http://download.oracle.com/javase/1.5.0/docs/guide/javaws/developersguide/syntax.html

De fato é intessente. Tinha como exemplificar? Ficou um pouco abstrato pra gente. A aplicação ficaria no servidor local e seria disparado para as estações? Mas como? Nas estações então não seria instalado o aplicativo? Quando iria disparar para as estações?

Clique nos links que postei acima que você já entende.

O JNLP se encarrega de fazer o download do servidor para a máquina cliente local e disparar a aplicação. Ele mesmo já inclui toda a parte necessária para a comunicação com o servidor. Sua aplicação tem a ilusão de estar rodando dentro da máquina local, mesmo estando numa máquina remota.

Eu tenho um pouco de experiência nisso porque tenho um sistema trabalhando nesse formato há uns 7 anos.

Trata-se de uma Indústria de Laminação Gráfica (meio complicado explicar o que eles fazem), na qual tem uns 16 computadores (Produção, Financeiro, Pedidos, Gerência, etc).

Tenho essa aplicação desenvolvida em Java Swing (que utiliza o banco de dados Firebird) e que é disparada com JNLP.

Na empresa tem um servidor (uma máquina protegida onde está instalado o banco de dados) do banco de dados, em todas as outras máquinas tem instalado o sistema, só que na verdade o sistema fica em um servidor na web (deixo em um servidor alugado no UOL), na configuração do JNLP eu deixei como permitido executar offline, ou seja, digamos que o computador esteja sem acesso a internet não vai haver problema e a aplicação vai executar mesmo assim.

Dessa forma toda vez quem houver uma atualização no sistema eu simplesmente aviso o funcionário que está precisando da alteração para fechar e abrir novamente o sistema, pronto sistema atualizado - mesmo porque eu raramente vou em pessoa até a empresa e geralmente estou há uns 600km de lá.

Pode não ser a melhor abordagem mas pra mim tem funcionado, como eu disse, há uns 7 anos.

Beleza, clareou bastante o assunto. Então nós criarmos um arquivo jnlp para ficar nas estações, que executará o aplicativo remotamente do servidor? Tem algum exemplo de configuração do arquivo jnlp?

Opa, posso estar muito errado, mas acho que foi explicado errado o conceito do Java Web Start.

no meu entendimento:

Ele é um “link” para a aplicação java que está no servidor, que é basicamente uma aplicação desktop.

Quando vc abre um arquivo destes o seu computador verifica se vc já tem ele instalado e se a sua versão é a ultima.

Se não tiver instalado ou não for a ultima ele faz download desse arquivo novo.

Dai pra frente é 100% desktop, client side.

Dai para conectar com o banco de dados é o processo padrão, vc configura a conexão com o servidor remoto e se comunica direto com o BD.

Ou seja é a mesma coisa que desktop, mas uma nova maneira de distribuição.

Não responde a pergunta de arquitetura, se é necessário criar uma aplicação servidora para gerenciar os clientes.

Minha resposta é não é necessário criar uma aplicação servidora para atender os clientes (encarece e dificulta o processo de desenvolvimento).

O Banco de dados gerencia as requisições de multiplos clientes com sobra.

Só é preciso atentar para usar Transaction quando for fazer uma logica que envolva mais de uma tabela, para não acontecer erros de integridade no banco.

[quote=heroijapa]Opa, posso estar muito errado, mas acho que foi explicado errado o conceito do Java Web Start.

no meu entendimento:

Ele é um “link” para a aplicação java que está no servidor, que é basicamente uma aplicação desktop.

Quando vc abre um arquivo destes o seu computador verifica se vc já tem ele instalado e se a sua versão é a ultima.

Se não tiver instalado ou não for a ultima ele faz download desse arquivo novo.

Dai pra frente é 100% desktop, client side.

Dai para conectar com o banco de dados é o processo padrão, vc configura a conexão com o servidor remoto e se comunica direto com o BD.

Ou seja é a mesma coisa que desktop, mas uma nova maneira de distribuição.

Não responde a pergunta de arquitetura, se é necessário criar uma aplicação servidora para gerenciar os clientes.

Minha resposta é não é necessário criar uma aplicação servidora para atender os clientes (encarece e dificulta o processo de desenvolvimento).

O Banco de dados gerencia as requisições de multiplos clientes com sobra.

Só é preciso atentar para usar Transaction quando for fazer uma logica que envolva mais de uma tabela, para não acontecer erros de integridade no banco.[/quote]

Olá,

Concordo plenamente com vc, o sistema de forma nenhuma é executado pelo servidor, mas sim com os recursos do terminal do cliente, o que o Java Web Start faz é simplesmente prover uma nova forma de distribuir um ou mais arquivos no formato .jar de maneira mais facil e rapida, com a vantagem da atualização automatica, estes arquivos precisam estar assinados por um certificado digital que pode ser valido ou criado por vc mesmo em sua empresa de desenvolvimento com os recursos do java mesmo.

A conexão e feita atraves de TCP/IP mesmo, e não por outro modelo, ou seja a velocidade de acesso a dados vai depender dos dois links de conexão, o link do servidor, e dos clientes, por isso falei anteriomente sobre boas praticas no desenvolvimento do sistema e do DB.

Sobre a questão do servidor estar offline, esta errado, caso o servidor estiver offline o sistema nao funciona, o que acontece no caso da explicação do amigo javer, ele armazena o Sistema (Arquivos do programa dele), e não o banco de dados (Servidor), em um servidor na uol, [quote]só que na verdade o sistema fica em um servidor na web (deixo em um servidor alugado no UOL)[/quote], isso sim e possivel, por exemplo, eu tenho um servidor b[/b] na empresa, e hospedo o sistema para download e atualizaçoes na web. Por isso que funciona offline, se a hospedagem web não estiver funcionando o sistema e o banco de dados vão se comunicar sem problema algum. Outra coisa, é possivel hospedar o DB na web também, mas ai é preciso ler o contrato de licença da sua hospedagem, pois a maioria delas entende acesso ilimitado e banco ilimitado dentro do proprio datacenter, e não conexoes TCP/IP de fora do mesmo, entao e preciso avaliar muito bem isso antes de fazer o uso de SGDBS remotos, agora vc pode alugar outro tipo de serviço web que prove varios acessos via TCP/IP remotos, mas o preço é beemmm diferenciado.

Att,
André Dalcin

Será que alguém poderia postar um exemplo de arquivo jnlp, para que nós fizéssemos as alterações de acordo com a nossa aplicação e testássemos na prática como funciona? Assim daria para entender melhor. Desde já agradecemos a disposição de todos.

Olá, de um salvar link como em cima deste link: http://www.brackeen.com/javagamebook/tilegame.jnlp

depois é so editar com o notepad ou qq outro editor

Att,
André Dalcin

Beleza.

Beleza. Fizemos as alterações, mas como ficaria o codebase, visto que o servidor de dados não está na web? Assim não pode ficar com http(exemplo do arquivo codebase=“http://www.brackeen.com/javagamebook”). Ele de apontar para o servidor desktop.

Fizemos as alterações mas deu erro. Veja como ficou:

<?xml version="1.0" encoding="utf-8"?>



AOS
Gemeos

Sistema de Arranjo de Ônibus
O AOS gerenciará o Arranjo de Ônibus, através de Cadastros, Consultas e Relatórios

<offline-allowed/> 

O erro foi o seguinte:
Não é possível iniciar o aplicativo. Erro:Não é possível carregar o recurso: file://Micro1/D:/Nossos Arquivos/ProjetoAOS/Projeto AOS/ProjetoAOS/aosjnlp.jnlp

O que pode estar acontecendo? Ele está tentando encontrar o jnlp no servidor? Ele não deveria localizar o jar?