Java.Net

Como escrevi no meu blog no Java.Net,
mas em Inglês seria interessante, falar um pouco disto em Português também.

Introdução
J/XFS - Java eXtensions for Financial Services, é um padrão gerenciado pelo Comitê Europeu de Normalizações-CEN, que descreve como você pode desenvolver para dispositivos ditos “financeiros”.

Por que só Financeiros?

Eu discordo nesse ponto, e acho que o termo Financeiro(Financial) tem uma conotação infeliz do ponto de vista de Markting desta API, pois parece que fica extremamente específico para grandes Bancos ou super empresas financeiras, e isto não é real num país de tecnologia desenvolvida como o Brasil, pois várias outras indústrias usam periféricos, como no ramo de Varejo, grandes redes de Lojas, redes de super-mercados, mas também empresas de menor porte, por que não?

Conceito “Escreva uma vez rode em qualquer lugar”(WORA)

Grandes implementações de periféricos acabam usando:

• Javax Communication API( se Windows)
• RXTX (se Linux )
• Milhares de comandos internos de periféricos, sendo estes a maioria ultra mal documentados

E ai o termo “Manutenção de Software”, ultrapassa as vergentes do aceitável para insuportável quando a tarefa consiste em manter um grupo de implementações para impressoras, pinpads, leitores de códigos de barra e vários outros simples dispositivos que você pode ver numa simples Loja de Conveniência no Brasil.

Quando você tem que sair de uma impressora EPSON modelo ayz para Diebold xyj, você vai pegar sua super classe de atributos estáticos com os comandos, ou um arquivo de properties/xml para não ser tão ruim, e vai ter um super trabalho na alteração dos comandos que definem o protocolo de “Pergunta e Resposta”.

J/XFS Resolve?

Sim, resolve! J/XFS não nasceu ontem, já está no mercado salvo meu engano ativamente desde 2000, e com isto vem chegando a uma certa maturidade, apesar de haver ainda muitas melhorias propostas que ainda podem ser inseridas no padrão pelo seu Comitê.

Mas resolve Como ?

J/XFS define algumas camadas, entre elas:

• Device Services (Drivers)
• DeviceManager
• DeviceControl

Precisamos de apenas uma para elucidar o conceito por trás deste especificação: DeviceServices, o qual vamos nos referir como Drivers J/XFS.

Você terá um conjunto de interfaces, constantes e classes que fazem parte do padrão de Drivers, o implementador do Driver, que geralmente é o mesmo que desenvolve o Hardware, implementa o driver de acordo com seus comandos específicos, tornando assim a chamada ao J/XFS padrão aos drivers sempre, e ai no momento da chamada o Driver sabe como desempenhar suas atividades. O grandioso é que você tem chamar o Driver, não se importando como isto é implementado por “trás das cameras”. Isto é como o uso de JDBC e a implementação de seus Drivers; quando você executa um “insert into …”, você não se importará em como o driver realiza estas operações no servidor de banco de dados. Sendo assim, J/XFS oferece ao mercado uma forma sempre padrão de desenvolvimento para dispositivos desta ordem.

E ai eu tenho WORA(Write Once Run Anywhere)?

Sim, porque você fala com os drivers padrão J/XFS e eles se encarregarão das atividades de baixo-nível por você.

Como escrever esses Drivers?

As experiências que tive no Brasil (2), me decepcionaram neste aspecto, visto que você pode implementar chamadas nativas usando as portas de comunicação, porém a maioria das pessoas usam as bibliotecas (DLLs ou SOs) e via Java criam uma capa JNI (Java Native Interface), que nada mais é que uma casca Java sobre uma biblioteca do sistema operacional.
Muito embora a BOA PRÁTICA seja implementar os Drivers em JAVA também, e inúmeras são as vantagens para isto, entre elas você não está preso a uma compilação para um determinado sistema operacional(ex: .dll=>Windows, .s0=>Linux). Além de portável é muito mais simples realizar estes tipos de Atividades em Java do que em C ou C++.

E por que isso não é embutido ao JME (Java Micro Edition) ?

Boa pergunta, eu infelizmente não posso responder isto, além de não ser um especialista em aplicações para Micro-Devices, não sei como isso poderia ser encaixado no ME [Comente isto ...Fique a vontade].

E por que uma JSR via JCP?

Esta pergunta é pior ainda de responder, isto envolve muito trabalho, e já conversei várias vezes com meu amigo Bruno Souza, entre as várias conclusões que chegamos, estão os fatos de que :

• Isto deve ser feito por EMPRESAS
• Isto envolve um bom tempo de trabalho
• Empresa+Trabalho não resulta em um trabalho “barato”, porém acredito que empresas deste segmento poderiam pensar em investir numa idéia como esta

Seria lindo ver javax.devices.api , mas por hora isto é sonho.

No Brasil, alguém usa?

Sim, eu fiz uma pesquisa outro dia sobre oportunidades de empregos envolvendo esta tecnologia, e para meu espanto havia uma boa procura, e com certeza ainda não responde a demanda de trabalho que há no mercado.

Grandes bancos utilizam, porém não me sinto a vontade de compartilhar estas informações, tendo em vista que são clientes da minha empresa, mas você encontra um edital público de um Banco do Governo se você for no Google :D.

As empresas Líderes de mercado

Os Espanhóis dominam o mercado mundial disto, tive o prazer de trabalhar e conhecer o trabalho de duas empresas que o Google também contará para você o nome delas! Eles são feras !

Boas Práticas

Nas duas oportunidades que trabalhei com J/XFS desenhei uma camada “lógica” de serviços, e implementei uma implementação de simuladores, e outra a real usando J/XFS, aplicando patterns como:

• Abstract Factory
• Template Method
• Factory Method
• Singleton

Outra dica, é que é bom você conhecer como criar e extender novos EVENTOS em LISTENERS em Java, pois sua aplicação pode precisar ser “responsiva” sempre, e “escutando” periféricos que se comunicam através as portas do computador.

Conclusão

Procurando uma API para estudar, fazer uma pesquisa, TCC, esta é uma, você vai quebrar cabeça um bocado no início, depois piora, depois você até se sente a vontade de fazer um post como este

Forte Abraço

Edgar Silva