Temos um PDV que roda em supermercado e estamos desenvolvendo também para bares e restaurantes, tenho que desenvolver a integração com: - PALM, Micro terminal e Impressoras não fiscais.
Iremos desenvolver um servidor para gerenciar os periféricos.
Antes de iniciar o desenvolvimento, pensamos em adiquirir o servidor de periferico.
Se alguem tiver interesse entre em contato no email gustavo.moda@gmail.com.
Quem tiver experiencia com isso, entre em contato também, podemos tercerizar.
Mas como acho difícil encontrar, gpstaria de uma opnião de vocês sobre o ASSUNTO.
Uso o JBOSS + EJB, ou, desenvolvo um servidor que ficará escutando as portas lpt, com e socket?
Sei que LPT e COM no java é um enrosco, ainda mais que terei que linkar com DLL dos fabricantes.
JBoss já faz a maior parte do trabalho
Impressoras fiscais (tipo Bematech) normalmente veem acompanhadas de drivers em c para interface com o dispositivo. Recentemente vi uma com uma bibliteca java (a própria bematech) mas essa era nada mais nada menos que uma bridge jni para a mesma dll em c.
O que eu quero dizer com isso é o seguinte: se vc for usar java com a bematech esteja preparado pra algumas dores de cabeça (que é comum em c).
Micro terminal? vc diz micro com bot remoto ? ou vc tá falando mesmo de um vt100 ou tispc?
Vamos separar um pouco as coisas só pra ver se eu entendi direito o que vc quer fazer.
Trabalhar com porta serial em java não achei ruim, funcionou bem para mim e existe uma api chamada javacomm que funciona. Com isso vc resolve a conversa com LPT + COMM e sem JNI(acessar dlls).
Impressoras fiscais, PDV, etc… Se existem dlls em C ou qualquer outra linguagem, aconselho vc a snifar a comunicação da DLL com a impressora e reproduzir isso em puro java com javacomm, retira a dependência do SO e ainda vc tem mais controle sobre os comandos, pois são poucos mesmo, acho que não chegam a 50 se me lembro bem.
Palms, Handhelds e demais, aconselho vc utilizar bluetooth que é o que o pessoal tem utilizado, tem APIs J2ME que fazem isso, ou em C# também tem algo que fala bluetooth para palm, e o “servidor” do bluetooth pode ser em java, ele vai ouvir um socket, e também tem API pronta pra isso.
Agora vc quer ter um servidor(JBoss + EJB), onde vc manda os comandos para esse servidor e ele reproduz isso nessas diversas interfaces que citei acima ? É esse o intuito do servidor ?
Se é isso, então vc não precisa de EJB, nem nada disso, vc tem que ter é um servidor Socket que fica escutando essas interfaces que estariam ligados ao computador, ou à alguma interface que um computador tenha acesso. E se por acaso vc queira ter algum serviço de monitoramento, aí vc pode até ter um “tomcatzinho” rodando pra vc colocar sua aplicação web, SEPARADA do servidor de suas interfaces/periféricos onde vc cria maneiras de consultar o status através de http, tcp, ou qualquer maneira que fique fácil da aplicação tomcat falar com a de periféricos.
Agora se eu não entendi nada do que vc disse, e escrevi um monte de besteira me avisa ae !
[quote=agodinhost]Impressoras fiscais (tipo Bematech) normalmente veem acompanhadas de drivers em c para interface com o dispositivo. Recentemente vi uma com uma bibliteca java (a própria bematech) mas essa era nada mais nada menos que uma bridge jni para a mesma dll em c.
O que eu quero dizer com isso é o seguinte: se vc for usar java com a bematech esteja preparado pra algumas dores de cabeça (que é comum em c).
Micro terminal? vc diz micro com bot remoto ? ou vc tá falando mesmo de um vt100 ou tispc?[/quote]
Bom, bemtaech tirei de letra, eles tem uma bliblioteca chamada bemaJava que faz o trabalho bem legal…
Ja rodo a 1 ano assim, porem. Outros fabricantes, como SWEDA está me dando dor de cabeca, tenho que usar FILE. para ler e enviar comandos.
Microterminal, é COLLTER, não tem boot… Microterminal mesmo.
Exemplo: GRADUAL e COLETER…
O duro e que tem uns que são iterfaces ip e outros com… Isso mata…
Valeu pela dica, vou ler muito sobre ela…
Pensei em criar uma classe de interface para aclopar qq printer… Nao sei se todas são somente textos… Vai que tem comandinhos do tipo: NEGRITO diretente nelas… É doideira minha fazer isso? Escrever drivers para cada modelo?
Nem todos permitem isso… Alguns microterminal vai via IP outros via COMM pela DLL.
Sair fora da DLL seria o melhor caminho… Vou tentar viabilizar isso… Java puro, vai rodar em LINUX fora com RUINDOWS.
Entao!!! Acho melhor ter um servidorzinho… E o banco? Hibernate?
Pensei no JBOSS pq a parte de transação eu nào me preocuparia… Saca!!! Fiz isso para sincronizar o pdv e ficou muito bommmmmmm!!!
Mas não sei se ele vai ficar consumir muita maquina para aclopar o servico de impressão, micro terminal e PALM …
Ainda estou dividido…
Acho o SOCKET mais simpes e ficaria mais enxutinho…
Acho o JBOSS mais robusto, esquema de transação prontinho…Mas nunca vi posts dele gerenciando perifericos…
Na verdade, a idéia que eu tinha quando concordei com o driver, era usar um sniffer e verificar os comandos que a DLL ou programa envia para o dispositivo, isso funciona mesmo sem documentação.
Pq não dá pra fazer com java ?? Eu já fiz e funcionou bem ! Usando javacomm eu tenho acesso à portas seriais sem problemas, a implementação do javacomm usa jni por baixo dos panos, mas existem implementacoes para varios SOs, e vc nao precisa ficar se preocupamento em vc mesmo cuidar do jni.
Já usei javacomm pra Windows, Linux e Windows CE.
Mas com certeza 30 dias é apertado, mas dependendo da quantidade de dispositivos diferentes vc pode conseguir.
Velho, dica: vai ser menos dor de cabeça se você fizer uma aplicação em C só pra isso e usar em java como aplicação externa. Muito menos dor de cabeça.
[quote=reinaldob] … isso funciona mesmo sem documentação.[/quote] Cara, leva mal não, se seu dispositivo for bem bobão isso até rola, mas na grande maioria dos casos o buraco é muito mais embaixo.
Não disse que não dá pra fazer em java - só que não acho (IMO) o mais indicado e nem o mais produtivo.
[quote=agodinhost]Escrever drivers de dispositivo em 30 dias? Nem que cada dia tenha 48 horas e que vc tenha saúde pra trabalhar full-time bro.
Vc iria precisar manjar muito do dispositivo (difícil pois às vezes a documentacão não é suficiente);
manjar muito de c ou assembler (não rola em java - no melhor caso java com jni acessando uma dll c);
IMO[/quote]
Periferico de itegracao é enviar comando em texto ou em bytes. No caso do microterminal for TCP/IP dá para fazer, se for COM já ferra tudo.
No caso da LPT, o envio e de bytes, mas concordo com vc, nesse caso, DLL. Senao nao rola.
Tenho esse prazo para intergrar o microterminal e as impressoras.
Não vejo problema em usar o S.O. para enviar comandos para a LTP ou COM…
O pessoal aqui viaja muito mano…
não existe mais JNI em Java depois que inventaram o JNA
use o JNA e se integre qualquer *.dll, *.so e afins, o bixo roda até em solaris mermão
Fazer interfaces e classes de periféricos é com certeza a melhor saida
mapei as rotinas utilizadas de maneira macro (acho que é sinonimo de ampla)
por exemplo para impressoras fiscais:
pois assim vc tera menos trabalho para implementar os drives.
JavaComm é moleza, mesma coisa que socket…
alias em Java, a melhor linguagem do mundo,
tudo que tem Input-Output-Stream é igual
3 linhas tu abre a porta e fica no read() do inputStream lendo os dados
e no write do outputStream escrevendo…
é isso cara, espero que você consiga entregar o seu trabalho a tempo,
se for só fazer ele, vc tem grandes chances
é que a mensagem do dyorgio parece aquele tipo de mensagem que o pedreiro novo diz à respeito do pedreiro velho qdo chega na obra: faço mais rápido e melhor …
