Olá pessoal, gostaria que apresentassem algumas formas de como criar a comunicação entre dois programas, pois quero saber quais opções eu posso ter.
Entao cara…
No momento só me passa pela cabeça duas opções:
1 - Arquivo xml onde uma salva e a outra lê
2 - Comunicação por sockets
RPC ou chamadas…
Filas.
http / webservices
Tudo dependeo do que você quer fazer.
[size=15]Serão varios programas de diferentes funções que devem se comunicar com um programa "servidor" onde estarão principalmente os dados a serem fornecidos e/ou gravados. Não quero envolver webservices ou algo realcionado a web, queria comunicação direta entre programa cliente e servidor, vou adicionar rotinas de backup de segurança de dados, checagem de conexão e outros detahes....[/size]- Se o servidor também for em Java, pode usar RMI (que é uma forma de RPC);
- Se não for, use Socket, em especial através da classe SocketChannel;
Haveria a possibilidade de usar CORBA, mas é complicação demais para resultado de menos, a menos que você queira investir em distribuição.
Já comecou a mostrar melhor o problema…
Os vários softwares serão feitos na mesma linguagem de programação? Vai ser java mesmo?
Os softwares vão rodar na mesma rede, mesmo domínio?
Pra mim seria interessante usar o protocolo HTTP para comunicação cliente e servidor. Não dá a dor de cabeça se você esquecer de fechar alguma conexão, e já tem uma infra-estrutura montada para atender esse protocolo (Apache HTTP Server e Tomcat, por exemplo). Você pode dar uma olhada em REST em http://www.infoq.com/news/2007/12/getting-started-rest
Qual e o problema em vc usar webservices?
se for para mesma rede o webservice nao apresenta o melhor desempenho…
mas ela nao especificou o que ele quer, quanto mais detalhes, melhor para a discussão.
Se essa base de dados dele puder ser usada por terceiros, fora da empresa, webservices na cabeça.
Olá
Não acople os 2 programas, apenas troque mensagens
-
Grave um arquivo (velho e bom csv) no disco com um programa e leia com o outro programa
-
Passe o arquivo por sockets
-
Despreze toda e qualquer sugestão que envolva RPC, inclusive as de web services com RPC
4, 5, 6, 7, …etc. KISS, Keep It Simple, Stupid
[]s
Luca
Como não conheço java a fundo eu colocaria a opção de…
O programa 1 criar um .txt ou xml com os dados
O programa 2 abrir o arquivo e receber as informaçoes e organiza-la
Luca,
eu sei lá, não gostei muito das sugestões, olha só:
Pra mim é a mesma coisa que eu dizer pra um amigo: “Olha, vou deixar os 50 reais que eu estou te devendo no cafezinho, pega lá pra mim?”. O caso normal é o meu amigo ir lá no cafezinho e pegar o dinheiro, e todo mundo ficar feliz. Mas pode acontecer de a) algum “sortudo” passar no cafezinho e pegar a nota ao invés do meu amigo; ou então b) alguém ter a mesma idéia que a minha e deixar 20 reais pra um outro amigo dele, e o meu amigo que não é bobo levar 70 reais pra casa. Em suma: como o “enviador” não tem controle do destino do arquivo, ele não pode tratar o erro se o receptor não receber o que queria.
A princípio parece uma boa idéia: o servidor abre threads, onde cada uma recebe um socket recém aberto, e cuja missão é tratar o que receber, escrever a resposta e fechar o socket. Simples não é? Porém, vários erros podem acontecer como: deixar threads “penduradas”, tratar mal as exceções de socket, esquecer de fechar sockets… E quando tenho que tratar não um tipo de requisição, mas vários? É um trabalhão danado! Servidores web fazem tudo isso, só que com o protocolo HTTP. Por isso, acho melhor usá-los do que reinventar a roda.
Tudo bem, acho bom desprezar SOAP, XML-RPC, UDDL, WS-* e essa sopa de letrinhas feita por otários e para otários. Mas eu não desprezaria REST, que acho excelente e muito promissor.
Bom, é isso.
Olá
Minha intenção foi puxar as respostas do tópico para enfatizar que primeiro se deve buscar as soluções mais simples que atendam ao problema.
[quote=Leonardo3001] não gostei muito das sugestões, olha só:
Pra mim é a mesma coisa que eu dizer pra um amigo: “Olha, vou deixar os 50 reais que eu estou te devendo no cafezinho, pega lá pra mim?”. [/quote]
Interpretação errada. Isto é exatamente o que a maioria das grandes, médias e pequenas empresas fazem a muitos anos e ainda chamam pelo nome bonito de EAI. Funciona muito bem e não ocorre o que você supõe.
A princípio parece uma boa idéia: o servidor abre threads, onde cada uma recebe um socket recém aberto, e cuja missão é tratar o que receber, escrever a resposta e fechar o socket. Simples não é? …[/quote]
Quem formulou a pergunta não especificou se os 2 programas estão na mesma rede ou não. Caso estejam confinados na mesma rede então com sockets NÃO acontece o cenário catastrófico descrito por você a menos que os programadores sejam muito bobos. Só para você entender como é fácil fazer algo assim que funcione corretamente, é como passam todas as milhares de transações do Banco Postal do servlet (Java) para o sofisticado switcher (C/C++). Na área de cartões de crédito é comum a integração via sockets.
Só para lembrar: os servidores web trabalham com sockets.
Tudo bem, acho bom desprezar SOAP, XML-RPC, UDDL, WS-* e essa sopa de letrinhas feita por otários e para otários. Mas eu não desprezaria REST, que acho excelente e muito promissor.[/quote]
Aqui houve uma interpretação apressada. Recomendei NÃO usar RPC. Esta recomendação vale para qualquer solução de integração de sistemas, inclusive web services sejam eles escritos usando SOAP, REST, JSON ou XML com um schema definido internamente.
[]s
Luca
Pessoal obrigado pela boa discussão gerada, vou detalhar mais a situação e o que quero:
-
o programa cliente e servidor estarão na rede interna da empresa;
-
esse conjunto de programas fará parte de um outro maior que eu pretendo implantar na empresa postertiormente;
-
Linguagem é “java total” desde interface até banco de dados e o que mais for necessário (custo de software deve ser ZERO!). Pretendo usar o seguinte conjunto: Eclipse + JasperReport/IReport + Visual Editor + Potsgree + Comunicação entre programas???;
-
o programa cliente(entenda-se vários simultâneamente) é bem pequeno, apenas criara informações de materiais que devem ser produzidos por outro setor(será basicamente Swing + envio de informações);
-
o programa servidor, além de guardar as informações, apresentará os pedidos conforme forem enviados em uma fila, e conforme forem sendo terminados será dado baixa e adicionado mais algumas informações. Tudo isso, ao final, servira para criar um relatório(que deve ser bem elaborado, pois será usado pela diretoria, Aiaiai!!!). Um sisteminha tipico do dia-adia.
Gostaria de saber as vantagens e desvantagens de cada tecnologia pois não conheço nenhuma ainda. Gravação e leitura de .txt ou XML está descartado. Preciso de conexão entre programas estável ao máximo.
Olá
Se o que você quer é comunicação entre cliente e servidor, então porque não usa o velho e bom servlet?
[]s
Luca
Utilize webservice e pare de sofrer.