No projeto que estou fazendo parte, o líder resolveu que é interessante manter os sistemas em C++ da maneira que estão atualmente, apenas com algumas adaptações para que estes consigam trocar informações com uma servlet Java.
A proposta que ele fez ao cliente (própria empresa) seria manter os sistemas em binário (para proteger as regras de negócios) e fazer com que as duas linguagens conversem via tcp/ip.
Andei estudando jni, rmi e webservices, e apenas este último foi aceito pelo líder, mas ficará para uma outra futura implementação.
Estou dando uma analisada no pacote java.net, mas ainda não encontrei nada que se encaixe com o que deverá ser desenvolvido aqui.
Agora a pergunta, alguém já trabalhou com proposta semelhante? E, se sim, qual a solução que achou mais convincente?
vc nao especificou o problema, mas talvez a solucao seja uso de sockets pra fazer a comunicacao.
Jose Jorge Jr.
E
Ederson_Soares
Desculpe se não fui muito claro.
A idéia a ser implementada é a seguinte:
A servlet fará uma requisição a aplicação c++ utilizando tcp/ip para executar uma tarefa distinta, e esta deve ficar retornando em determinado intervalo de tempo um status sobre a execução em andamento.
Uma segunda saída seria a servlet solicitar a execução daquela aplicação, e esta somente passaria o status quando solicitado, também através de tcp/ip.
Para a segunda saída, eu colocaria o status em um tabela de processos no banco de dados e pegaria as informações nesta, mas foi preterida esta idéia por aqui até que não haja outra solução melhor.
Então este é motivo do questionamento, qual seria a melhor solução para este caso? Será que a utilização de sockets seria suficiente?
Att.
Ederson.
smota
Sockets, Sockets, Sockets
Você na verdade vai escrever um servidor que vai ficar esperando comandos em determinada porta e a partir desses comandos ele interage com sua aplicação.
O servlet só vai conectar nesse servidor e prozear com ele :shock:
Neste caso Webservices, RMI e JNI não vão ajudar muito … Webservice é xarope (vai ter q fazer em C ou usar Java com JNI) e terá uma performance muuuuito fraquinha. RMI não dá porque sua aplicação é em C++ … e JNI, bem, fique longe enquanto puder
vamorim
Desculpe, mas por que Web Services não são adequados para esse caso, visto que já foi tão falado que Web Services são recomentados para comunicacão com sistemas legados?
E
Ederson_Soares
Agradeço a colaboração de todos.
Vou estudar mais sobre sockets para conseguir um bom trabalho.
Grato.
Ederson.
louds
O ruim de usar sockets é que voce tem que fazer todo (un)marshalling na mão e isso é muito contra-producente. Webservices é lento pacas, talvez uma solução seja usar CORBA que é suportada por ambas linguagens e acelera bastante o processo.
smota
Hummm … tinha esquecido do CORBA, é, pode ser por ai mesmo.
Mas Louds (ALERTA: posso estar falando besteira) … o (un)marshalling só será um problema se o protocolo que ele adotar for meio complexo, não? tipo, se ficar só num troca troca de mensagens texto onde vem um comando e volta uma msg de resposta (nada de objetos & cia) isso vai ser bastante simples …
louds
“smota”:
Mas Louds (ALERTA: posso estar falando besteira) … o (un)marshalling só será um problema se o protocolo que ele adotar for meio complexo, não? tipo, se ficar só num troca troca de mensagens texto onde vem um comando e volta uma msg de resposta (nada de objetos & cia) isso vai ser bastante simples …
Sim, se for algo do tipo send/ack (->pula! <-pulei!) ate que sim, mas acho que isso é raro. Vale lembrar de outro problema, normalmente sistemas em c++ sofrem com encodings diferentes de ASCII ou latin-1.
Bom, existe outra opção que seria mandar xml’s pelo wire, a performace seria um pouco melhor que WS.
Luca
Olá
Muito bem lembrado este alerta sobre encodings, big endians, etc. Para corroborar vou lembrar para não usar Strings nos sockets.
Use array de bytes, array de bytes, array de bytes…array de bytes…[size=“5”]array de bytes[/size].
[]s
Luca
Fabio_Kung
usar Sockets com SOAP, nesse caso seria melhor do que com Corba, ou XML?
E
Ederson_Soares
Olá a todos.
A idéia inicial do projeto seria:
1.Opção:
Servlet aciona processo feito em c++;
Por uma tela no browser, o usuário ficaria visualizando o status do processo que requisitou, pois é uma leitura um tanto extensa de arquivos com mais de 32 mbytes que necessitam passar por diversas condições antes de subir para a base de dados;
Opção:
Servlet aciona processo feito em c++;
O processo ficaria enviando o status da execução de tempos em tempos.
Cheguei a analisar o RMI, Sockets, WS, menos o CORBA, mas foi a opção de transmissão de informações via TCP/IP que a empresa determinou para ser utilizada nesses primeiros projetos.
Estas duas opções foram determinadas para que encaixassem no atual escopo da empresa, pois atuaram muitos e muitos anos com codificação em C e C++ e a mudança para Java está um tanto quanto encrencada por diversos paradigmas que estamos tentando quebrar aos poucos, e por isso estamos buscando uma solução que mostre a eles que este novo mundo é diversas vezes melhor que o anterior, mas vou deixar de delongas…
