Translate

sábado, 30 de outubro de 2010

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 :)

Nota do autor: esse post foi sugerido por Jerry Varela de Manaus/AM.

4 comentários:

MPantoja (from Brazil) disse...

Parabéns, Fagner! Excelente artigo, muito didático e esclarecedor. Segue sugestão para que o autor nos traga novos artigos, aprofundando a questão das lacunas do XFS, principalmente quanto aos novos dispositivos que vêm sendo lançados no mercado e sua adaptação a esse framework, como por exemplo os leitores de cartões sem contato, os periféricos biométricos etc.

Anônimo disse...

Exclente artigo Fagner. Muitissimo obrigado por compartilhar conosco!!!

Anônimo disse...

Parabéns Fagner. Para quem esta ingressando neste mundo de drivers, seu artigo faz entender as dificuldades do meio. Obrigado.

Anônimo disse...

Thanks mate, very useful!