Preciso criar um processo q irá servir determinada tarefa pra mim. Considere essa tarefa como sendo um programa em background, isso mesmo, um programa.
Então, eu terei um servidor q irá executar esse processo (imagine esse processo como sendo um prompt do windows), esse programa irá ficar em standalone e o servidor irá esperar até q alguém se conecte e peça para executar algo no processo (prompt do windows). Imagine q o cliente peça para listar o conteúdo de tal diretório.
Qd chegar mais de uma requisição o servidor irá colocar os pedidos em uma fila, esperando até q o processo anterior termine para poder executar o próximo pedido.
Blz!?
Agora, estarei rodando isso na mesma máquina, não vou fazer nenhuma requisição externa, ou seja, de outra máquina. Preciso criar um servidor utilizando TCP pra isso?
O processo q irei rodar é um sistema q a empresa utiliza e já fiz alguns testes e funciona perfeitamente. O problema é q acho q um servidor utilizando TCP… é muita coisa, não é?
Eu poderia criar um programa q assim q executado abra um processo novo(prompt do windows), execute a tarefa e termina o programa, mas isso é muito custoso. Imaginem se vários programas deste estiverem rodando ao mesmo tempo, a máquina explode… rsss
Limitando minha resposta apenas na escolha da tecnologia listo os seguintes argumentos:
Dependendo da pressa e do quanto lhe pagam faça o mais simples usando scripts.
Caso 1 seja simplório demais e inviável, use TCP pois é possível que no futuro as coisas não fiquem na mesma máquina
Usando TCP, adote sockets e controle as coisas manualmente.
Caso controlar manualmente seja inviável, pense na possibilidade que os processos rodarem como métodos remotos. Neste caso RMI provê tudo o que precisa.
Caso precise rodar em rede e os processos devem estar em uma WAN sem VPN, considere a possibilidade de passar os objetos por http. Neste caso RMI não serve e você vai precisar serializar objetos ou usar web services.
Certo, muito bem lembrado! A gente fica tão hipnotizado por hypes (web services por exemplo) que as vezes esquece de soluções mais simples para ligar Java com Java.
[quote=Luca]1. Dependendo da pressa e do quanto lhe pagam faça o mais simples usando scripts.
2. Caso 1 seja simplório demais e inviável, use TCP pois é possível que no futuro as coisas não fiquem na mesma máquina
3. Usando TCP, adote sockets e controle as coisas manualmente.
4. Caso controlar manualmente seja inviável, pense na possibilidade que os processos rodarem como métodos remotos. Neste caso RMI provê tudo o que precisa.
5. Caso precise rodar em rede e os processos devem estar em uma WAN sem VPN, considere a possibilidade de passar os objetos por http. Neste caso RMI não serve e você vai precisar serializar objetos ou usar web services.[/quote]
Realmente Luca, utilizar script não dá. O processo vai exigir manipulação de templates e estou utilizando Velocity pra isso. Tb faço conexão com BD.
A propósito estarei utilizando rede local, nada externo. No máximo poderei fazer requisições de outra máquina, mas isso não está no projeto.
Nunca precisei implementar nada parecido com esse sistema e tudo isso é novo pra mim. Já fiz uns testes com ServerSocket e Socket, funciona legal, mas ainda não testei com RMI. Vou dar uma olhada nisso.
[quote=Luiz Henrique Coura]
Nunca precisei implementar nada parecido com esse sistema e tudo isso é novo pra mim. Já fiz uns testes com ServerSocket e Socket, funciona legal, mas ainda não testei com RMI. Vou dar uma olhada nisso.[/quote]
Você não acha que utilizar um Stateless Session Bean é mais simples que trabalhar com Sockets na unha?
Ou que tal você utilizar Servlets? Seu cliente pode chamar o servidor fazendo simples requests HTTP.
Abraços,
Marco Campêlo
Sun Certified Idiot Ideas Specialist
Hum, se você não quer usar um Tomcat (web) ou JBoss (ejb) da vida, e seu servidor é especializado para certos protocolos, você pode tentar algo parecido com o que foi feito com o James (james.apache.org), que foi construído sobre o Avalon ( http://excalibur.apache.org/ ). Não estou recomendando o Avalon, mas a idéia está aí.
Bom, o sistema q irá processar os dados que o usuário requisitou está na rede interna. Temos servidores Tomcat rodando aplicações, mas está na rede externa e nesta rede não tenho acesso ao programa q preciso e tb aos dados q ficam num sistema de discos internos.
A minha idéia seria criar um servidor simples, por socket na rede interna, somente para prover uma instância de um ou mais processos (que é o nosso sistema) para que esse(s) possam tratar determinada tarefa do usuário e jogar essa informação no BD. Essa requisição não virá de um usuário externo, mas de um usuário(sistema) interno. Acontece q essas requisições podem ser multiplas e preciso organizá-las para q meu sistema possa processá-las.
Poderia instalar um servidor Tomcat na rede interna, mas acho q não tem necessidade. Naverdade já criei o servidor e agora estou gerando as threads q irão processar o trabalho pra mim.
Pretendo estudar RMI para implementar a mesma coisa, mas por enquanto estou sem tempo e pretendo deixar alguma coisa pronta, já operacional.
Andei lendo o q o pessoal passou, mas isso é muito novo pra mim e estou tentando não atropelar as coisas.
Enfim, agradeço a ajuda de vcs e os links. Já marquei esse topic no meu bookmark. Ainda tenho muito q estudar!
Hoje em dia Web Services estão na moda (por exemplo, eles permitem que você possa ter um sistema com .NET e Java na mesma empresa sem grandes problemas de interoperabilidade).
Que tal usar Tomcat e Web Services? É meio pesado (e põe pesado nisso), mas é quase “click and go” dependendo da ferramenta que você tiver.
Dê uma estudada nisso que acho que pode te ajudar bastante!