Olá pessoal, o meu problema é o seguinte, desenvolvi uma aplicação desktop que se comunica com outras máquinas na rede compartilhando da mesma base de dados (servidor Postgres). A minha dúvida é a seguinte, como faço pra dar um refresh em tempo real em uma tabela de vendas por exemplo, ou de um cadastro qualquer, quando em outro terminal um cliente faz uma inclusão, exclusão ou alteração na base de dados. A idéia é, por exemplo: Se um cliente faz a inclusão de um produto em uma máquina atualiza automaticamnete a table da tela correspondente na outra máquina sem a necessidade de fechar a janela ou prover um evento.
Alguém poderia sugerir um framework ou um procedimento pra ser adotado nesse caso ?
Nota: desconfio que tenho q usar Threads monitorando a base de dados … [me corrijam se eu estiver errado] (Se estiver certo como fazer ?)
O ideal é usar um serviço de mensageria. Se sua arquitetura utilizasse Swing + EJB, você poderia usar JMS para enviar uma mensagem para os clientes, que saberiam quando precisariam se atualizar.
no acesso ao banco to ulilizando Hibernate JPA.
E em relação a sua resposta, é q ainda dou os meus primeiros passos no Java, e gostaria de um exemplo mais específico ou um direcionamento mais amplo para q eu possa pesquisar a respeito e chegar a um resultado satisfatório … O q sugere ?
Então, no teu caso eu acho melhor implementar o padrão ‘Observer’ (que inclusive é utilizado em EJB MDB Topic). Mas na minha opinião, EJB não é a melhor forma, pois você precisa que seja tempo real e o MDB não garante isso. E também porque não é legal fazer comunicação socket com um desktop dentro do MDB.
Sobre ficar fazendo refresh em uma tabela, não parece ser a melhor forma também, pois vai consumir muitos recursos.
[quote=pozzo]Então, no teu caso eu acho melhor implementar o padrão ‘Observer’ (que inclusive é utilizado em EJB MDB Topic). Mas na minha opinião, EJB não é a melhor forma, pois você precisa que seja tempo real e o MDB não garante isso. E também porque não é legal fazer comunicação socket com um desktop dentro do MDB.
Sobre ficar fazendo refresh em uma tabela, não parece ser a melhor forma também, pois vai consumir muitos recursos.
Por isso, na minha opinião, eu faria uma implementação ‘comum’ de Observer (http://en.wikipedia.org/wiki/Observer_pattern).[/quote]
Náo precisa ser um MDB. Bastaria apenas o session bean que faz a persistência enviar uma mensagem para os clientes de forma assíncrona. E seria em tempo real sim. Tão logo os clientes recebessem a mensagem, eles fariam o refresh nos dados.
Se ele utilizar Observer como você sugere, ele acabará reinventando um serviço de mensageria…
[quote=tnaires][quote=pozzo]Então, no teu caso eu acho melhor implementar o padrão ‘Observer’ (que inclusive é utilizado em EJB MDB Topic). Mas na minha opinião, EJB não é a melhor forma, pois você precisa que seja tempo real e o MDB não garante isso. E também porque não é legal fazer comunicação socket com um desktop dentro do MDB.
Sobre ficar fazendo refresh em uma tabela, não parece ser a melhor forma também, pois vai consumir muitos recursos.
Por isso, na minha opinião, eu faria uma implementação ‘comum’ de Observer (http://en.wikipedia.org/wiki/Observer_pattern).[/quote]
Náo precisa ser um MDB. Bastaria apenas o session bean que faz a persistência enviar uma mensagem para os clientes de forma assíncrona. E seria em tempo real sim. Tão logo os clientes recebessem a mensagem, eles fariam o refresh nos dados.
Se ele utilizar Observer como você sugere, ele acabará reinventando um serviço de mensageria…[/quote]
Entendi que você havia dado a sugestão de EJB, quando você disse: “Se sua arquitetura utilizasse Swing + EJB”. Mas concordo contigo, usando JMS apenas, acho que ficaria legal. Sendo que cada cliente swing seria um ‘cliente/servidor jms’.
Mas, apesar de ‘reinventar a roda’ na implementação do Observer, acho que ficaria bem simples no caso dele. Na minha opinião, em alguns casos uma solução mais simples pode ser melhor.
Eu imaginava tipo:
Quando o Session Bean q fa a persistência fizesse inert, update , delete. Manda uma mensagem em uma determinada porta.
E por sua vez a controller inicia uma tread q ficasse escutando uma porta para detectar alteração no banco para atualizar a table.
Bom imaginei uma coisa nesse sentido, mas me corrijam c estiver errado. C estiver me digam mais ou menos nesses meros detalhes como devo fazer … Pode ser uma simples ilustração do q devo fazer c não for pedir mto.
Me diga uma coisa: quantas camadas físicas tem sua aplicação?
Perguntando de outra forma, entendi que sua aplicação tem view, controller, dao, etc. Mas todas essas classes ficam no lado do cliente? Ou você tem parte da aplicação rodando no servidor?
[quote=tnaires]Me diga uma coisa: quantas camadas físicas tem sua aplicação?
Perguntando de outra forma, entendi que sua aplicação tem view, controller, dao, etc. Mas todas essas classes ficam no lado do cliente? Ou você tem parte da aplicação rodando no servidor?[/quote]
A idéia é q a aplicação seja padrão pra tdos os terminais da rede, possuindo as funções de cliente e servidor.
Vamos lá. Você pode desenvolver a aplicação de duas formas:
:arrow: A primeira, que acredito que é a que você está fazendo, consiste em escrever um programa que faz tudo: apresentação de dados com Swing e persistência dos dados em um só. Esse programa rodará em cada máquina cliente e conversa com o SGBD diretamente, sem intermediários.
Pra essa arquitetura você pode pesquisar um pouco sobre o protocolo UDP. Quando uma das aplicações gravasse os dados, enviaria um broadcast pela rede para avisar as outras que os dados foram atualizados. Elas ficariam escutando esse aviso por uma determinada porta e, quando recebessem o pacote, fariam o refresh.
:arrow: A segunda forma consiste em separar a aplicação em duas partes: uma, que chamaremos de cliente, conteria apenas o Swing da coisa, cuidando apenas da apresentação dos dados. A outra parte rodaria no servidor e ela quem seria responsável pela persistência dos dados: essa parte roda em um software chamado servidor de aplicações. Nesse cenário, sempre que sua aplicação Swing quisesse persistir ou consultar dados, conversaria com algum componente no servidor - esse componente pode ser um EJB - e ele cuidaria de conversar com o banco.
Nesse caso seria simples usar um serviço de mensageria como o JMS. Quando o EJB gravasse os dados na tabela, enviaria uma mensagem para os clientes. Eles, por sua vez, quando a recebessem, fariam o refresh. O JMS não é complicado de aprender e evita que você tenha que fazer tudo na mão.
Então amigo, já fiz um software semelhante usando socket UDP e TCP. Um chat so q ele tinha um servidor e um cliente rodando separados como vc disse.
Se eu quisesse modificar a estrutura da minha aplicação para a segunda estrutura citada, como faço pra usar esse tal JMS ? Uma breve explicação viria a calhar
sem querer bancar o folgado é claro … rssssss…
Obrigado pela ajuda até o momento foi d grande valia.