Estou em um dilema aqui no trabalho e gostaria de sugestões por parte de vocês. Tenho um projeto web aqui que comunica-se com hardware via protocolo UDP. Para resolver esse “desafio”, foi criado uma espécie de middleware, que comunica-se com o hardware e com o banco de dados. Dessa forma, a aplicação web não tem necessidade de conversar diretamente com o hardware, interfaceando somente com o banco. Até aí tudo bem, o projeto foi muito bem sucedido.
PORÉM…
Agora surgiu a necessidade de fornecer o suporte a esse hardware para aplicativos de terceiros. A ideia é disponibilizar uma biblioteca com as funções de comunicação, de forma que quem deseje integrar seu software com esses hardwares, utilize essa biblioteca. A ideia levantada na reunião do projeto foi a de transformar o middleware em uma DLL. Aí, pelo menos ao meu ver, o bicho pega. O middleware foi todo codificado em Java. No Java, eu consigo acessar uma DLL via JNA. Eu consigo também exportar uma biblioteca simplesmente na forma de um Jar. Mas… e pra transformar isso em uma DLL? Que possibilite a importação em aplicativos, por exemplo, feitos em Delphi ou mesmo em C#? Estou analisando possibilidade de recodificar todo o middleware em C++ ou talvez C#… ainda não sei.
Por isso peço a opinião de vocês aqui do fórum. Quais soluções eu teria nesse caso?
Não acredito que foi todo em Java. Com certeza tem JNI/JNA no meio. Remova a ponte JNI/JNA e escreva a API usando C++.
Eu, francamente, não usaria Java pra comunicação com hardware.[/quote]
Deveria acreditar , se é UDP (protocolo de rede) não depende de coisas de “máquina” e portanto não é necessário C++ ou coisa assim. Apenas um Socket. E java tem socket :lol:
Estou em um dilema aqui no trabalho e gostaria de sugestões por parte de vocês. Tenho um projeto web aqui que comunica-se com hardware via protocolo UDP. Para resolver esse “desafio”, foi criado uma espécie de middleware, que comunica-se com o hardware e com o banco de dados. Dessa forma, a aplicação web não tem necessidade de conversar diretamente com o hardware, interfaceando somente com o banco. Até aí tudo bem, o projeto foi muito bem sucedido.
(…)
Por isso peço a opinião de vocês aqui do fórum. Quais soluções eu teria nesse caso?[/quote]
Se é um protoclo de rede qualquer um poderia implementar em qualquer outra linguagem/plataforma que tenha sockets.
Me dá a impressão que ha um acoplamento ao banco de dados de alguma forma.
Mas porquê implementar um DLL ? O que vc quer ganhar com isso ? Porque simplesmente não vende o middleware “as is” ? Ou apenas ajustando ele para separar a parte que lê o protocolo da parte que escreve no banco de dados. Middleware em java é muito melhor porque roda em qualque ambiente. DLL só funciona no windows.
Ok que vc poderia fazer em C++ e compilar para vários OS, mas vale a pena ?
A forma mais simples de atender o requisito é ajustar o que já tem sem reimplementar. Eu usei uma vez um produto que tinha um protocolo de rede proprietário e utilizada outro protocolo de rede (em xml) para comunicação com sistemas. Na realidade era um webservice primitivo ( naquele época não se falava de webservice).
A ideia seria então que o middleware em java traduza para webservice (REST se possivel) e ai qualquer projeto em qualquer tecnologia pode utilizar esse serviço. Inclusive vc pode modificar o que tem hoje e transformar a parte que escreve em banco de dados em um cliente desse middleware em vez de ser parte do middleware.
Dito isto, se vc não quiser usar java ou não quer ter um software separado a solução é ir para o nativo mesmo. Ai usaria C++ para criar a lib , compilar para linux ou windows e usar jni/jna do java para comunica com a lib. Mas eu só iria por este caminho se realmente o outro for impossivel já que o caminho do middleware é muito mais simples e rápido de vender , instalar e fazer upgrade depois, e sendo em java é independente do OS.
Não acredito que foi todo em Java. Com certeza tem JNI/JNA no meio. Remova a ponte JNI/JNA e escreva a API usando C++.
Eu, francamente, não usaria Java pra comunicação com hardware.[/quote]
Deveria acreditar , se é UDP (protocolo de rede) não depende de coisas de “máquina” e portanto não é necessário C++ ou coisa assim. Apenas um Socket. E java tem socket :lol: [/quote]
Bom, primeiro com relação ao comentário do Ataxexe, sim, esse middleware foi feito inteiramente em Java, usando os sockets UDP.
Com relação ao comentário do sergiotaborda, acredito que não seja possível comercializá-lo da maneira como está hoje, pois existem diversas convenções entre o middleware e o software web de gerenciamento, que acredito que inviabilizariam isso. Hoje, está funcionando com base em requisições / respostas utilizando o banco de dados. O aplicativo web coloca uma requisição, o middleware lê, conversa com o hardware e salva uma resposta no banco, que é então lido pelo aplicativo web. Em algumas situações, o hardware realiza algumas requisições, que o middleware verifica na base de dados e devolve uma resposta ao hardware. Devido a esse comportamento, e ao fato do middleware estar bastante ligado a lógica do banco de dados do software de gerenciamento, acho difícil utilizá-lo como ele se encontra hoje. O que preciso fazer é uma solução que possibilite às empresas parceiras adicionarem suporte a esse hardware em seus aplicativos. Inicialmente pensei em simplesmente modificar a parte que faz interface com o banco, criando algumas classes que realizem este papel, e fornecer simplesmente como um Jar. Ok, mas e se o aplicativo que for integrar não for em Java? Pensei em fazer em uma DLL, pois mesmo que o aplicativo fosse em Java, conseguiria integrar via JNA, e não restringiria a softwares em Delphi e C# (que acredito que serão as realidades mais comuns nesse caso).
