Desenvolvendo Drivers XFS - Overview

Olá leitores,

Atendendo à pedidos, vou postar aqui um overview sobre o desenvolvimento de drivers

XFS. Eu estava evitando postar artigos tão técnicos, pois este blog também é lido por
pessoas leigas. Mas, sou refém de minha palavra. Assim, se você não é desenvolvedor, e
nem quer ser, melhor então não perder tempo lendo a este post (mas não temas, pois
mais posts interessantes e orientados ao público em geral estão por vir!).

Vamos lá então. Vou começar falando um pouco da motivação e escolhas do ponto de

vista da empresa que tem que fornecer drivers, e depois entro na parte mais técnica,
explicando as conseqüências dessas escolhas e como lidar com elas.

Escolha: XFS, J/XFS ou padrão proprietário?

Se você trabalha em uma empresa que fornece equipamentos para a automação bancária
e comercial, diretamente para o cliente final, então você muito provavelmente deve ter tido
essa discussão internamente em sua empresa. Qual a melhor escolha, para montarmos a
infra-estrutura de drivers do equipamento? Devo projetar tudo em XFS, J/XFS ou faço a
coisa funcionar em um padrão proprietário? Bem, normalmente são as demandas dos
clientes que nos auxiliam nessa tomada de decisão. Afinal, não adianta você construir sua
infra-estrutura em um padrão proprietário, se seus clientes não quiserem fazer uso desse
padrão em suas aplicações! E sua empresa não vai querer perder projetos com potencial
de milhões de reais, só porque ninguém havia pensado em investigar um pouco o que o
mercado demanda em relação a essa questão.

Pois bem, no que diz respeito ao mercado de ATMs e terminais de auto-atendimento em

geral, se você é uma empresa que fornece esses equipamentos, então você pode
descartar o padrão proprietário (para a camada de negócio), e você terá que adotar o
padrão XFS e também o J/XFS. O fato é que o mercado usa XFS, a maioria dos bancos o
usam, então essa é a primeira infra-estrutura na qual você terá que investir. Quanto ao
padrão J/XFS o fato decorre do advento da expansão de tecnologias como Java e Linux
(vide meu post: Guia da Automação Bancária para Iniciantes). Assim, importantes bancos
como Caixa Econômica Federal e Banco do Brasil estão utilizando drivers J/XFS em seus
ATMs e terminais financeiros, e essa tem sido realmente uma tendência. A prioridade é
menor do que a necessidade de um driver XFS, mas é importante que você planeje ter
uma infra-estrutura em J/XFS, até para tentar aproveitar o trabalho a ser realizado junto ao
desenvolvimento do driver XFS.

Agora, se você é uma empresa que fornece dispositivos a serem utilizados na automação
bancária e comercial em geral, é mais provável que você consiga atender a maioria de
seus clientes, utilizando até mesmo um padrão proprietário para a camada de acesso ao
dispositivo. Isso ocorre porque em geral, o teu dispositivo é parte de uma solução maior
(exemplo, você fornece a impressora térmica que é utilizada em um ATM), e a
responsabilidade de fornecer a infra-estrutura de drivers da camada de negócio (ou seja, a
parte que fará interface com a aplicação), é em geral da empresa que está fornecendo
essa solução integrada final.

Qual versão de XFS?

Se você já decidiu que, o que você precisa é uma infra-estrutura XFS, então essa será sua
próxima dúvida. O padrão XFS existe há muitos anos, e já se encontra na versão 3.10 de
drivers e especificação. No entanto no mercado, ainda existem clientes que utilizam o
antigo XFS 2. Nesse caso, não há muita dúvida, prefira sempre a versão mais atual
disponível para a infra-estrutura. A própria especificação fornece meios de construir sua
infra-estrutura de modo que a mesma funcione sem problemas mesmo sendo acessada a
partir de uma aplicação baseada em XFS 2.
Em geral, ao longo da evolução da especificação XFS são adicionados novas classes de
dispositivos. No entanto, também é comum haver correções para as classes já existentes,
e é por isso que os mecanismos oferecidos de interoperabilidade entre versões XFS é
importante, pois você poderá projetar seu driver para levar até isso em consideração, e
com uma única infra-estrutura de driver, você poderá atender a um número maior de
clientes, usando seja lá qual for a versão do padrão XFS.

Mãos à obra: Por onde eu começo?

Até aqui você, desenvolvedor, estava levantando informações para a tomada de decisão
de sua empresa. A decisão final cabe, em geral, ao gerente de projetos, e uma vez que a
decisão foi tomada, será responsabilidade sua e de sua equipe, o desenvolvimento da
infra-estrutura de drivers no padrão escolhido. A boa notícia é que essa é a parte mais
legal do processo :)

Dirimidas todas as dúvidas da tomada de decisão, o momento agora é de realizar

downloads! Você terá que fazer o download dos seguintes itens: especificação XFS e
SDK, todos coincidentes a versão escolhida. Vamos tomar como exemplo um driver XFS
na versão ultima que é a 3.10. Nesse caso, você conseguirá o download dos dois itens no
seguinte endereço: CEN WS/XFS.

Com esse material em mãos, você precisará ler, pelo menos, aos documentos da Part 1 -
API/SPI Programer's Reference e Part 2 - Service Class Definition -
Programmer's Reference. E além desses dois você precisará também ler o documento
referente a classe que especifica o tipo de dispositivo para o qual você quer construir o
driver XFS. Por exemplo, se você quer desenvolver um driver XFS para uma impressora
térmica, então a classe de dispositivo em questão é a PTR, e você encontrará sua
especificação no documento CWA 15748- 3.

Conseqüências: Plataforma de desenvolvimento e execução

A tomada inicial de decisão, resultará na definição da plataforma de desenvolvimento da
sua infra-estrutura de drivers, e também definirá em que plataforma de sistema
operacional ela poderá ser executada.

Se a sua escolha foi por desenvolver a infra-estrutura em XFS, então você deverá saber
que sua infra-estrutura somente executará em sistemas Windows. Deverá
ter consciência também de que a plataforma de desenvolvimento terá que ser uma que
permita a criação de DLL. O SDK do XFS é baseado na API da linguagem C. Por isso,
como plataforma de desenvolvimento o melhor é utilizar C ou C++.

Veja que se a escolha tivesse sido desenvolver um driver J/XFS, então

as conseqüências seriam bastante diferentes, uma vez que você teria que desenvolver
todo ou a maior parte do código em Java, e a solução final seria multi-plataforma, ou seja,
executaria em sistemas Windows e também Linux.

Desenvolvendo o driver
Abaixo segue uma figura que mostra a arquitetura de uma solução executando em XFS.
Aqui, a sua responsabilidade está na camada mais inferior da solução, que é o Service
Provider. Você terá pelo menos um Service Provider, para cada classe de dispositivo que
compuser a sua solução, mas você poderá ter um Service Provider por DLL ou uma DLL
para vários Service Providers, ou ainda uma única DLL para todos os Services Provider
existentes em sua solução (não recomendo essa ultima abordagem):
Sua DLL precisará exportar todas as funções com o prefixo WFP, especificadas no
capítulo 6 do primeiro documento da especificação. Abaixo segue uma imagem extraída
do Dependency Walker, onde são listadas as funções exportadas por uma DLL que
implementa um Service Provider:

Além de exportar essas funções em sua DLL, você terá também que implementá-las de
acordo com a especificação, atentando principalmente para o comportamento esperado
para cada uma delas. Isso é assim, justamente para que a idéia de se ter um framework
realmente funcione. Veja que o objetivo do framework XFS é permitir que aplicações sejam
desenvolvidas para a automação bancária e comercial, de uma maneira independente da
plataforma de hardware. Quando a especificação é atendida, normalmente os clientes tem
livre escolha de fornecedores de hardware, e geralmente utilizam muitos dos principais
fornecedores para compor seu parque de equipamentos na produção, e tudo isso
utilizando uma única aplicação, que não possui qualquer característica técnica amarrada a
nenhum desses fornecedores. Essa é a idéia e é por isso que é necessário se atendar
para o que diz a especificação.

Você notará que todas essas funções exportadas são comuns a todos os drivers XFS,
sejam eles drivers que atendam a classe PTR (impressora), ou a qualquer outra classe. Na
verdade, o comportamento específico de cada classe só vem à tona a partir da função
WFPExecute. É com essa função que se acionam os comportamentos ou "comandos"
específicos de cada classe de dispositivo.

Olhando a especificação, você verá que essa função recebe vários parâmetros de
execução. Dentre eles está o parâmetro dwCommand. É nesse parâmetro que você
receberá a identificação do comando que a aplicação do cliente quer executar junto ao
dispositivo implementado pelo seu driver. Por exemplo, se a aplicação quisesse solicitar o
status de sua impressora térmica, então ela preencheria esse campo com o valor definido
na constante: WFS_INF_PTR_STATUS. E você teria que construir a resposta a esse
comando, tomando por base o que diz a especificação no documento da classe PTR. Você
notará nesse documento, que todos os "comandos" são identificados por constantes como
essa aí, e se dividem em duas categorias: Info Commands, para comandos de
informações a cerca do dispositivo e Execute Commands, para comandos de ação junto
ao dispositivo. Abaixo segue uma listagem dos comandos suportados pela classe PTR do
XFS 3.10:

Você precisará então, ler com atenção a especificação da classe de dispositivo que você
está implementando, para que o seu driver se comporte o mais próximo possível do
esperado segundo essa especificação.

Como saber se está tudo certo?

Após algum tempo trabalhando com XFS e J/XFS, você notará que as especificações tem
brechas ou lacunas. Essas são partes das especificações nas quais um determinado
detalhe não ficou tão claro quanto deveria, causando margem a erros de interpretação.
Isso ocorre com freqüência, e é realmente um problema para os bancos e demais clientes
que utilizam esses padrões, assim como para os fabricantes que fornecem esses drivers.
Pois cada um implementa a refirada parte da especificação da maneira que interpretou, e
no final das contas um comportamento ou retorno que deveria ser sempre esperado,
acaba por ser diferente para cada fornecedor.

Uma boa estratégia é o cliente criar um documento com uma especificação mínima do
XFS, contendo todos os retornos e comportamentos que ele espera de um determinado
driver XFS. Claro que para dizer que o produto final disso é XFS, terá que se fazer essa
mini-especificação baseada na especificação XFS oficial. O fato é que após criado esse
"documento de aderência", os fornecedores poderiam adequar seus drivers para que se
comportem exatamente conforme o cliente quer, atendendo a especificação XFS do ponto
de vista do cliente. Para o cliente isso é muito bom, mas algumas empresas fornecedoras
não vêem isso com bons olhos, pois essa estratégia facilmente implicaria em ter uma infra-
estrutura de drivers XFS para cada cliente, o que aumenta os custos de manutenção das
empresas fornecedoras. Bem, nem tudo é perfeito :)

Um exemplo dessa estratégia é adotada na Espanha, onde um orgão local, equivalente a

nossa Febraban, determina que os bancos somente podem comprar terminais de auto-
atendimento que sejam certificados/homologados por uma entidade certificadora ,
normalmente uma empresa terceira (Dynasty TG, nesse caso), a qual basicamente avalia
se a infra-estrutura do fornecedor está minimamente aderente ao padrão XFS nos moldes
esperados pelas aplicações em execução nos bancos daquele país. Assim, os
fornecedores interessados, entram em contato com a Dynasty TG, para submeter seus
Drivers XFS ao processo de certificação, e uma vez aprovados, o fornecedor passa a ser
reconhecido como um fornecedor certificado e apto a realizar vendas de seus ATMs e
terminais de auto-atendimento para os bancos daquele país.

Bem é isso :)

Autor
Meu nome é Fagner Souza, sou especialista em automação bancária e comercial com
larga experiência em sistemas de Auto-Atendimento. Meu website é
http://www.fagnersouza.com.br/, e nele você pode encontrar meus contatos.