Translate

sábado, 21 de maio de 2016

Protótipo de Placa de Sensores e LEDs: Hardware e Firmware

Olá leitores. Hoje trago um projeto simples de placa de sensores e leds, baseado na plataforma Arduino. O bacana desse projeto é que ele pode servir de base para exercitar vários dos conceitos que utilizamos na automação bancária. Por exemplo, podemos criar um device driver para controlar essa placa, e depois podemos criar um service provider implementando a classe SIU do XFS.

Antes de falar sobre o projeto, vou falar um pouco sobre a plataforma Arduíno. Aqueles que gostam de eletrônica certamente já ouviram falar de Arduíno. Trata-se de uma plataforma para prototipagem de projetos de eletrônica, muito utilizado também por entusiastas do "faça você mesmo". O Arduíno é open source e é fácil. Existe uma infinidade de versões de placa Arduíno, originais e compatível, que variam basicamente em relação a quantidade de entradas e saída que a placa pode controlar. Também existe uma infinidade de módulo de hardware, como sensores, motores DC e outros tipos de atuadores, que você acopla a sua placa Arduíno facilmente. Na parte da programação, existem muitas bibliotecas prontas que você pode reutilizar, e que vão auxiliá-lo na codificação do seu firmware, usando o compilador do Arduíno que é simples e bem intuitivo. Talvez a versão de placa Arduíno mais comum seja a Arduíno Unon da imagem a seguir. Essa é, inclusive, a versão de placa utilizada no nosso projeto.



Existem placas Arduíno originais (como essas da imagem) e existem também aquelas que são compatíveis. Como se trata de um projeto open source, qualquer pessoa um pouco mais hábil em eletrônica pode criar a sua própria "construção" de placa Arduíno. Assim, existem na Internet uma infinidade de placas compatíveis. Pode haver algumas variações de qualidade dos materiais e até mesmo em formato dos conectores, mas as placas compatíveis tem basicamente as mesmas capacidades da placa Arduíno original. Geralmente elas são mais baratas, então a escolha vai de cada um. Eu, por exemplo, preferi comprar a versão original até como uma forma de incentivo ao projeto Arduíno. Dai que minha placa é original e enviada direto da Itália.

Pois bem, abaixo exibo o esquema da placa de sensores e leds, mas antes de prosseguirmos fica um alerta: sou apenas um simples entusiasta de eletrônica, não um engenheiro eletrônico. Então, me perdoem por eventuais faltas de otimazação nesse circuito. O conceito desse esquema é servir a um Terminal de Consulta (kiosk), dotado de uma porta (para acesso ao micro, impressora e demais dispositivos), uma leitora de cartões, uma impressora térmica, sinalização luminosa e sonora, sensoriamento de luz, temperatura e nível.



A esquerda do esquema vemos a placa Arduino Uno. O projeto poderia ser feito com outras placas Arduino, inclusive com as versões menores como a Arduino Nano. Eu escolhi a Arduino Uno porque é esse o modelo que tenho em casa. Os demais componentes do projeto são:
  1. Leds: o objetivo desses leds é a sinalização para o usuário. Nesse projeto, eu considero que um desses leds é para indicar a inserção de cartão na leitora e o outro para indicar a saída de papel na impressora térmica;
  2. Buzzer: sinalização sonora para o usuário. Por exemplo: podemos soar um alarme caso a porta do cofre seja aberta sem a devida autenticação no sistema, ou podemos simplesmente chamar a atenção do usuário para uma ação requerida da parte dele. Podemos variar a intensidade do som que é emito pelo Buzzer, logo esse componente trabalha com valores contínuos, em uma escala que sai de 31 e vai até 65535, para a placa Arduino Uno;
  3. Button Switch: o papel desse componente é indicar porta do cofre ou gabinete aberto ou fechado. Esse componente portanto, só pode assumir dois valores: aberto ou fechado;
  4. Resistores: o papel desses componentes no circuito é evitar que os leds se queimem ou que haja curto circuito na placa, no caso do resitor ligado ao Button Switch;
  5. Potenciômetro: permite configurar a sensibilidade do sensor de temperatura. Em outras palavras, indica a partir de qual temperatura o sensor deve alarmar;
  6.  Sensor de Temperatura: indica a temperatura ao redor de um ponto. Esse sensor poderia estar espalhado pelo o equipamento em série, para indicar, por exemplo, tentativas de arrombamento com maçarico; Esse sensor pode ser configurado com um resistor ou potenciômetro, para alarmar somente quando a temperatura atingir um certo limite. Portanto, os valores fornecidos por esse sensor partem de um valor mínimo e vão até o limite máximo, que depende das características físicas do sensor. Normalmente consultamos o datasheet do modelo/fabricante do componente para obter esse tipo de informação;
  7. Sensor de Nível: indica se houve uma inclinação. Portanto, esse sensor fornece os valores: nivelado ou inclinado; 
  8. Sensor de Luz: indica a incidência de luz em um ponto. Esse também é um sensor que fornece valores de mínimo e máximo de acordo com o limite fisico do sensor, definido pelo modelo/fabricante;
  9. LCD: esse é um componente acessório no circuito. Eu o inclui apenas para mostrar os dados de entrada e saída da porta serial. Ou seja, o uso desse componente é complemente opcional;

Eu mantenho esse projeto no site AUTODESK 123D CIRCUITS. Esse site permite criar e simular circuitos Arduino, incluindo a parte do firmware. O link para o projeto da placa é esse: Sensor and LED's Board. É uma plataforma colaborativa também. Então, se quiserem fazer modificações, fiquem à vontade.

Segue abaixo um trecho do código fonte para controlar o firmware dessa placa. Trata-se de um código em C\C++ padrão Arduíno, e de fácil leitura. Quando falo firmware, me refiro ao software embarcado no microcontrolador da placa Arduino. É ele que permite controlar as entradas e saídas da placa de acordo com as necessidades do projeto. Cada pino de entrada ou saída recebe uma identificação no código. Dependendo do tipo de pino, você pode usar comandos de leitura ou aplicar uma tensão (ligar) algum componente conectado ao pino. O Arduino inclusive oferece algumas bibliotecas prontas para você fazer isso de forma mais facilitada e de acordo com o componente que estiver conectado nos pinos. LiquidCrystal.h é um exemplo de biblioteca Arduino para controle de LCD. Um firmware Arduíno tem basicamente a seguinte estrutura, conforme exemplo abaixo:



As funções setup() e loop() são obrigatórias. A função setup() é executada durante o carregamento do firmware e ocorre somente uma vez para cada carregamento, seja quando a placa é ligada ou quando é resetada. É um bom local para inicialização de variáveis e configurações em geral, já que será executado apenas uma vez. No exemplo acima, eu estou configurando os pinos que estarei utilizando, indicando quais serão pinos de entrada e quais serão de saída. Configuro também a velocidade da comunicação Serial e o tamanho do LCD que está acoplado a placa Arduíno; A função loop() será executada eternamente em laço, ou seja, assim que ela terminar sua execução, o microntrolador a executará novamente desde o início. Portanto, é nessa função que a inteligência do firmware deverá ser programada. No exemplo acima, eu verifico se há dados disponiveis na porta serial e os leio. Depois disso utilizo sub-funções (não exibidas ai nesse exemplo), para processar o dado recebido na porta Serial. Por fim, eu escrevo no LCD todas essas informações e finalizo o loop processando tarefas que estiverem pendentes. O firmware desse projeto foi programado para responder a seguinte lista de comandos:


Basicamente temos:
  • Comando "S": comando de leitura do status dos sensores. A resposta é uma String no formato "Sddddd", onde 'd' pode ser 0 ou 1, de acordo com o estado do sensor. Para os sensores de valores contínuos como o sensor de temperatura e luz, foi configurado um valor limite para considerar quando a resposta deve variar entre 0 e 1;
  • Comando "LCd": comando para ligar/desligar LED da leitora de cartão. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar piscante;
  • Comando "LPd": comando para ligar/desligar LED da impressora térmica. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar piscante;
  • Comando "Ad": comando para ligar/desligar BUZZER. A posição 'd' pode ser 0, para desligar, 1 para ligar ou 2 para ligar alarme;


Acessando o projeto "Sensor and Led's Board" você consegue visualizar o código completo do firmware. Você consegue também executar e simular esse projeto, para exercitar esses comandos e o comportamento dos sensores e atuadores previstos no projeto. Basta cliclar em "Start Simulation", para que o circuito seja "ligado":


Clicando em "Code Editor" você tem acesso ao código fonte e também ao "Serial Monitor":


Por meio do "Serial Monitor" você pode simular o envio de dados na porta serial da placa. Basta digitar um texto e clicar em "Send". Com isso, você envia as Strings dos comandos mencionados anteriormente para ver o circuito ganhar vida. Exemplo: envie "S" para obter os status dos sensores. Envie "A2" para ouvir o BUZZER alarmar, e "LC1" ou "LP1" para ligar um dos LEDs. Se você tiver esses componentes em casa e uma placa Arduino, você pode também baixar o código fonte do firmware nesse mesmo link e instalá-lo no seu Arduino e dai fazer o teste no teu próprio hardware.

Com esses comandos básicos essa placa permite criar, por exemplo, um Service Provider XFS, que poderia ser facilmente integrado em uma aplicação FrontEnd para um Terminal de Consulta (kiosk). Para isso, basta primeiro criar um Device Driver para controlar essa placa. Ou seja, uma interface de comandos de alto nível que possam ser mais facilmente integradas em outro software. Poderiamos ter nesse Device Driver apenas duas funções públicas:

  • String readSensor();
  • void setIndicator(int indicatorID, int indicatorValue)

Com um device driver pronto, basta escrever um Service Provider XFS da classe SIU (Sensors and Indicator Unit Device), cuja especificação está contida no documento CWA 10 de cada versão da especificação XFS. Essa especificação pode ser baixada aqui, na sua versão mais recente: CWA 16926-10.

É isso. Espero que aproveitem esse projeto e façam suas próprias experiências.

Até mais!!!

quinta-feira, 26 de março de 2015

Fraudaram meu cartão de crédito

Olá leitores. No inicio de Fevereiro tive meu cartão de crédito (com chip) fraudado pela primeira vez na vida. Curiosamente, amigos meus reclamaram recentemente de terem seus cartões fraudados. Então, o objetivo desse post é tentar analisar como a fraude aconteceu. Antes de prosseguirmos, gostaria de frizar que eu não tenho experiência em sistemas TEF, portanto, talvez uma ou outra informação aqui não seja lá muito acertiva (fique a vontade para postar uma correção nos comentários).

A fraude ocorreu em um Sábado de poucas compras. Por isso, eu sei exatamente em qual loja a fraude ocorreu. O que importa saber dessa loja, é que tipo de sistema ela possui como meio de pagamentos. Nesse caso, a loja utilizava um sistema PDV (não sei o fabricante) com uma máquina para TEF, ou seja, um ETFPOS. Essa é uma configuração típica de lojas de médio porte, onde a manuntenção de estoque é importante. Pois bem, o processo de pagamento ocorreu como habitual, entreguei o cartão, a balconista introduziu o cartão na leitora e eu digitei a senha. Em nenhum momento o cartão saiu do alcançe de minha visão.

Na Segunda-feira seguinte a essa compra, recebi um telefonema do meu banco perguntando se eu havia feito uma compra de passagem aérea no Sábado e outra momentos antes da ligação. Eu disse que não e a operadora informou que meu cartão havia sido fraudado e que, portanto, ela queria permissão para cancelar o cartão. Permissão concedida de imediato e perguntei: as compras realizadas foram efetivadas, ou só ficaram na tentativa? Ela respondeu que nenhuma compra havia sido efetiva. De fato, mais tarde consultei o extrato online do meu cartão de crédito e nenhum lançamento anormal foi notado.

Pois bem, com essa descrição já é possivel supor o que ocorreu:

O fraudador não foi bem sucedido na captura de todos dados do meu cartão. Ele conseguiu apenas parte do conjunto de dados que seriam necessários para realizar uma transação fraudulenta mais tarde. Digo isso porque, provavelmente, as compras de passagem aérea que ele tentou realizar ocorreram em uma loja on-line e, como se sabe, para uma transação como essa são necessários diversos dados do cartão como: número do cartão, nome impresso no cartão, e data de validade do cartão, além do CVV. Algumas lojas inclusive exigem o endereço da fatura do cartão e o CPF (nem todas pedem essa parte). Desses dados, somente o número do cartão é armazenado eletronicamento no cartão. Normalmente, mas nem sempre, o número impresso no cartão coincide com o PAN que compõe os dados da Trilha 2 do cartão. Tentar realizar uma compra on-line sem qualquer uma dessas informações, tipicamente resultará em uma transação mal sucedida, e foi o que ocorreu. No entanto, o que me tirou alguns momentos de tranquilidade foi não entender como o fraudador conseguiu os dados eletronicos do meu cartão. Como ele conseguiu obter o PAN do meu cartão?

Suponho que ele tenha fraudado o sistema PDV do estabelecimento, colocando um programa espião no computador onde está instalado a aplicação PDV. Após a seleção da aplicação CREDITO do chip, a aplicação executa a leitura de uma série de dados do cartão, para compor os dados necessários para envio de uma transação EMV de autorização da compra junto a operadora do cartão. O envio dessas informações é encapsulado em uma mensagem, tipicamente no formato ISO 8583. O canal de comunicação entre o computador do PDV e o servidor da solução (ainda antes de chegar nos servidores da processadora de cartões) é, tipicamente, criptografado usando SSL ou uma VPN. Então, o que deve ter ocorrido é que o fraudador capturou os dados que compõe essa mensagem, antes dela ter sido enviada e diretamente no computador.

Por sorte, acredito que a balconista do estabelecimento não estava envolvida na tramóia. Se estivesse, então a fraude poderia ter sido completada com êxito. Afinal, passei a ela meu CPF (nota fiscal paulista), e ela já tinha meu nome completo e endereço (entrega da mercadoria comprada). Só faltariam CVV e validade do cartão, que podem ser facilmente memorizado em apenas uma ou duas olhadas no cartão. Normalmente entregamos o cartão à pessoa do outro lado do balcão e isso facilita essa captura de informações. Com a prática atual da nota fiscal paulista, que a maioria utiliza para praticamente todo o tipo de compra, a inserção do CPF é o caminho para obter o nome do possivel titular do cartão, uma vez que o própria receita federal oferece serviço de consulta pública a essa informação a partir do CPF. Assim, os demais dados do cartão (CVV e data de validade) e o teu endereço de cobrança são as únicas informações que podem evitar uma fraude, caso você tenha a infelicidade de ter seu cartão de crédito inserido em um sistema comprometido.

Você tem outra explicação para essa fraude? Poste abaixo os seus comentários...

Até mais!!!


quinta-feira, 5 de fevereiro de 2015

Retrospectiva 2014

Olá senhores leitores. Após um longo período de ausência por conta do desafio - superado - de um mestrado, eu estou de volta e espero poder publicar artigos com mais frequência a partir de agora.

Nesse primeiro artigo de retorno vamos abordar rapidamente os principais acontecimentos de 2014.

Ano passado (2014) foi um ano cheio de acontecimentos ruins para a área de automação bancária e autoatendimento. Demissões, problemas de fraude, aquisições, todas essas coisas juntas colocaram bastante pressão no profissional dessa área e, são fatos que devem desencadear um 2015 mais nervoso. Mas tivemos coisas boas também!! Acompanhem:

Demissões e outras mudanças no setor
Esse ultimo ano foi um ano cheio de rumores de demissões, algumas confirmadas e outras abafadas (não se encontra nada que confirme). Empresas importantes do setor demitiram em massa. Por exemplo, a Perto Periféricos para Automação demitiu uma enorme quantidade de funcionários, em praticamente todas as suas filiais no Brasil. O plano de demissões, ao que parece, atingiu todos os setores, pois foram para a rua desde técnicos de campo, passando por pessoas da área administrativa e chegando inclusive aos engenheiros e projetistas de software. A boa notícia é que uma boa leva desse contingente foi absorvida pelas demais empresas do setor. Tradicionalmente a Tecban é a empresa que mais contrata ex-funcionários Perto, mas é certo que outras empresas do setor também absorveu parte dessa mão de obra. Não se sabe (entenda-se: eu não sei), porque essas demissões ocorreram. Como um ex-funcionário da Perto, o que eu posso dizer é que ela é uma empresa que, até 10 anos atrás, tinha uma estrutura familiar, onde imperava a meritocracia. Com isso, as pessoas tinham acesso a promoções, desde que desempenhassem bem o seu papel. No entanto, depois de muitos anos na empresa, e parado em um mesmo cargo, o profissional começa a se tornar mais caro do que as opções no mercado, e dai a empresa realizava "ajustes", que resultavam em demissões. Normalmente a ordem era pegar em cada setor os colaboradores com maior salário, e simplesmente cortar os dois que estivessem encabeçando a lista. Isso ocorreu várias vezes nos quase 10 anos em que estive por lá, e pode ter sido isso o motivador dessa onda em 2014. Fato é que, todos os meus antigos colegas de trabalho foram embora nessa ultima leva :(

Outra empresa que demitiu forte ano passo foi a Scopus Serviços. O motivo ficou claro mais tarde: a Scopus Serviço foi vendida para a IBM. Essa é uma mudança importante no cenário nacional, pois marca o retorno de uma das grandes potências do mercado de automação bancária. A IBM já foi um grande player nesse mercado, mas nos últimos anos esteve concentrada em negócios de menor envergadura no setor. Com essa aquisição, ela volta a ter importância no setor, principalmente porque a Scopus Serviços era responsável pela manutenção do enorme parque de ATM (quase 35 mil) do Bradesco. Vale lembrar que a IBM vem correndo por fora no setor já há alguns anos, ou seja, ela nunca deixou de atuar nesse setor. Na parte de cooperativas bancárias, a presença dela é forte, principalmente no fornecimento de soluções de back-end. No grandes bancos, naturalmente, todos os que usam soluções baseadas em Mainframe, são clientes da IBM. No entanto, a importância dessa aquisição é que ela está aumentando a importância de seus negócios na outra ponta: ATM, embora mais concentrada em serviços (que é o negócio mais rentável).

No que se refere a aquisições, como se sabe, em 2013 a OKI Eletronic havia adquirido a maior parte da Itautec. Mas foi no ano passado, porém, que surgiu a nova empresa: OKI Brasil. Isso aqui foi uma boa notícia no setor, pois a OKI Brasil já nasce assim: grande. Trata-se de uma empresa que consegue oferecer soluções em praticamente todos os domínios da automação bancária e autoatendimento. Embora muito mais forte na automação comercial, parece que OKI Brasil trabalhou bem sua linha de produtos para conseguir sinergia entre as áreas (muitas empresa não conseguem fazer isso), e com isso aumentou fortemente sua oferta de produtos e serviços. Uma visita ao seu website deixa claro que eles vieram para comandar. Acabaram de completar 1 ano de vida, e nesse primeiro ano teve todo aquele trabalho de integração do seus mais de 4 mil funcionários e etc, mas agora 2015 pode ser o ano em que eles virão para cima dos demais players do mercado, aumentando a concorrência - o que é ótimo para nós, profissionais da área. Um desafio da OKI Brasil, que talvez não se imagine a princípio é: se manter como principal fornecedor do Itaú. Isso mesmo, a Itautec, naturalmente, era o principal fornecedor do Itaú e não só de ATM. Então, a OKI Brasil está ai, mas isso não quer dizer que eles irão assumir a posição de preferência da extinta empresa (não faria sentido para mim). Acho que o Itaú agora deve estar abrindo concorrência para empresas como a Diebold, quando o assunto é fornecimento de ATM e talvez esteja abrindo o mesmo tipo de concorrência para Unissys quando o assunto é o fornecimento de PC e estações de trabalho. Enfim, a OKI Brasil tem bastante trabalho para 2015, mas sem dúvida o projeto é vencedor, os Japoneses vieram para ficar.


Fraudes no autoatendimento
Esse é um assunto delicado pois, como profissional do setor, eu não posso falar o nome das entidades bancárias que foram acometidas por fraude. Mas posso sim falar do tipo de fraude que mais ocorreu em 2014 e de seus estragos. Realmente não temos muita novidade em termos de novas técnicas, os fraudadores exploraram falhas já bem conhecidas que não deveriam existir mais nos ATM e sistemas de autoatendimento. Isso reflete o maior defeito do ser humano: ele relaxa e esquece. Muitas das fraudes do ano passado foram baseadas em técnicas simples e já bem difundidas de ataque, tanto aqui no Brasil quanto em outros locais do mundo. Por exemplo: boot de um sistema operacional diferente a partir de um Pendrive; Acesso administrativo ao próprio sistema operacional do ATM e etc. Todas essas fraudes poderiam ser evitadas com soluções já bastante conhecidas: criptografia do HD associada a criptografia local do Dispensador de Cédulas, acesso restrito ao BIOS do PC e impossibilidade de boot a partir de USB. A parte relativa a criptografia do dispensador já é padrão atualmente. Todos os fabricante já entregam o seus dispensadores de cédulas com a opção de ativação do modo criptográfico. Já a criptografia do HD, no entanto, encontra resistência pois envolve investimentos relativamente altos: aquisição de um produto e visitação aos ATMs do parque para atualização tecnológica (talvez haja opções a isso). Quando o assunto é segurança, infelizmente, só há investimento depois que o ladrão mostra a cara. Então, os bancos afetados ano passado, todos eles, iniciaram projetos de atualização tecnológica voltada para segurança, incluindo sistemas de criptografia do HD. Tarde, já que estima-se no setor que algo em torno de 30 milhões de reais tenha sido roubado dos ATM, só em 2014, somando todas as fraudes e todos os bancos afetados. Seguramente esse número está subestimado, já que os bancos não revelam esses valores (vamos conhecendo nas conversas de corredor e etc). Ocorre que as fraudes, embora utilizem técnicas conhecidas e relativamente simples, têm sido cada vez melhor organizadas, envolvendo centenas de pessoas em várias localidades diferente em todo o território nacional e ao mesmo tempo! O desafio realmente, é se manter alerta, não relaxar, não achar que suas medidas são suficientes. Já se sabe há muito tempo que os fraudadores possuem em seus quadros: engenheiros, técnicos, projetistas, advogados e toda sorte de pessoas altamente capacitadas. Ou seja, hora ou outra, encontrarão outra brecha para atacar.

O que esperar para 2015?
Francamente, eu estou preocupado, há rumores negativos no setor, embora os principais bancos tenham registrado um aumento em seus lucros no último ano: Bradesco, Itaú-Unibanco, Santander. As empresas fabricantes, no entanto, não registram esses lucros gigantes e, como se viu em 2014, vem reduzindo seus quadros. Isso normalmente ocorre por dois motivos: perspectivas de problemas na economia e preparação para fusões. Estamos vivendo exatamente o primeiro cenário, há um clima crescente de incertezas na economia do Brasil, e isso é ruim para todos nós, profissionais do setor, pois se a economia vai mal, a indústria segura os investimentos, isso congela salários, isso segura novas contratações e, eventualmente, resulta em demissões. Enfim, o que podemos fazer é torcer para que passemos por esse período difícil mais ou menos sem sobressaltos em nossas carreiras.

É isso senhores, feliz 2015 para todos nós!!!

terça-feira, 3 de dezembro de 2013

Autoatendimento para o canal ATM: Overview sobre o Front-End

        Olá senhores leitores. Após um longo período de ausência, estou de volta com mais um artigo interessante sobre autoatendimento em terminais do tipo ATM. Vou falar um pouco sobre a arquitetura das soluções de autoatendimento, e com isso quero apresentar aos leitores, o que está envolvido nesse tipo de aplicação, quais são os principais elementos arquitetônicos da solução como um todo, e também localmente, quando se ajusta a lente para olhar mais próximo a composição da aplicação que controla os terminais. O objetivo deste artigo, como sempre, é mostrar para o jovem uma visão mais geral a cerca dessa indústria, e o que ela pode oferecer de desafios e recompensas. Agora vamos ao que interessa!

Uma solução completa de autoatendimento envolve dezenas de software dispostos em três pontos da arquitetura da solução: Front-End, Middleware e Back-End. Esses termos são utilizados largamente na engenharia de software para designar o propósito do software em questão, e na arquitetura de uma solução de autoatendimento, Front-End designa o software cujo propósito é oferecer algum tipo de interface (não necessariamente gráfica) para algum tipo de usuário (cliente, operador, gestor e etc). Por meio dessa interface, são oferecidos serviços que serão processados no Back-End. Esse termo designa, portanto, o software que executa normalmente em ambientes de servidores (pequenos, médios ou grande porte), mas que têm funções relativas ao processamento e efetivação das transações que compõem cada um daqueles serviços. Em uma solução de autoatendimento, essas são transações bancárias, típicas de produtos como depósito e conta corrente, os quais são exemplos de produtos bancários encontrados em sistemas que compõem o Back-End. Já o termo Middleware, normalmente está associado a qualquer tipo de serviço localizado entre as duas outras camadas citadas. A monitoração remota do terminal ATM, o serviço de parametrização desse terminal e também o serviço de atualização remota, normalmente estão localizados nessa camada.

Considerando a indústria das instituições bancárias, e sua estrutura de TI, fisicamente, o Back-End é representado, em muitos casos, por um computador de grande porte denominado Mainframe. Esse computador hospeda a maioria do software e demais elementos que compõem o Back-End na arquitetura. Esse software é responsável, por exemplo, por autorizar boa parte das transações, além de conter os principais programas responsáveis pelos produtos mais básicos de uma instituição financeira, como a conta-corrente e etc. O conjunto mais básico desses produtos bancários é designado como Core Banking, e todas as instituições bancárias possui uma solução dessa natureza, seja feita dentro da própria instituição, seja adquirida pronta no mercado. Não importa quantos canais de atendimento essas instituições possuam, por exemplo, ATM, atendimento telefônico, internet banking e etc. Todos eles terão, em algum ponto, que se submeter ao Mainframe, usando uma ou mais transações servidas por ele, acessando portanto, componentes do Back-End.

O Middleware é ponto da arquitetura onde normalmente se localizam sistemas de gestão dos canais. O gestor de cada produto da instituição, normalmente irá precisar de relatórios estáticos, e também configurar parâmetros de operação das transações. Bom, é aqui que começa a confusão. Veja, qualquer instituição tem diversos canais de atendimento como citei anteriormente. Imagine se essa instituição tiver que desenvolver no Back-End uma transação de saldo para Internet Banking, outra versão da transação de saldo para o canal ATM, e por fim, um para o canal de atendimento telefônico. Isso seria um caos, certo? Seria não, é! O fato é que muitos bancos encontram-se exatamente nessa situação, pois sua solução de autoatendimento não foi projetada para operar diversos canais ao mesmo tempo. É até fácil de entender, alguns canais só foram considerados bem recentemente, com o advento de alguma nova tecnologia. Por exemplo, smartphone é uma realidade agora, todo mundo tem um, mas não era assim há cinco anos. Revisar toda a arquitetura sai caro e, principalmente, pode resultar em muitos problemas para os clientes até estabilizar. Por isso, ocorre que muitas instituições acabam por manter estruturas com essas fragilidades arquitetônicas. Outras instituições que tiveram a chance de revisar sua arquitetura procuraram concentrar no middleware soluções de convergência entre os diversos canais. Componentes localizados no middleware intermediam as transações entre os diversos canais e o Mainframe. Assim, uma única versão, e um único formato de transação ficam disponíveis no Host, e o Middleware é o responsável por tornar essa transação acessível aos diversos canais, no formato que eles esperam. Isso é conhecido como solução multicanal.

O Front-End é a nossa praia. Esse ponto da arquitetura é onde se encontra a interface com o cliente em cada um dos canais. Assim, no canal ATM o Front-End é a aplicação de autoatendimento no terminal ATM, incluindo todas as demais aplicações utilitárias e de serviço que compõe os componentes desse ponto da arquitetura. Em um canal de atendimento telefônico, seria o sistema baseado em URA. Óbvio que o Front-End de cada um dos canais de atendimento tem suas complexidades, e eu vou detalhar aqui um pouquinho da complexidade envolvida no canal ATM. A aplicação de autoatendimento para o canal ATM é um dos principais componentes do Front-End na arquitetura de qualquer solução de autoatendimento quando falamos de automação bancária. A complexidade envolvida nessa aplicação pode ser observada na imagem a seguir. 


A primeira questão que se tem que observar é que a aplicação precisará controlar os periféricos do terminal de autoatendimento. O ATM na imagem pode ser um terminal caixa eletrônico ou um terminal eletrônico do tipo kiosk. Eles são normalmente encontrados em bancos, shopping centers, aeroportos ou até mesmo em lojas de conveniência. O conjunto de periféricos encontrados nesses terminais depende do modelo do terminal. Por exemplo, um ATM do tipo Full Fuction, normalmente possui módulo depositário, dispensador de cédulas, leitora de cartões, impressora térmica, placa de leds e sensores, painel do operador e pinpad. Já um terminal do tipo kiosk é encontrado normalmente na seguinte configuração: impressora térmica, pinpad e leitora de cartões. Claro que com o advento de novas tecnologias de hardware, diversos novos periféricos vem sendo adicionados a esses terminais: leitoras de smartcard, leitores biométricos, câmeras videofotográficas (normalmente uma WebCam) e etc. Veja que a configuração do terminal determina o escopo de atuação da aplicação. Para cada um dos periféricos contidos nessa configuração, será necessário um software controlador. Esse software é denominado como Device Driver. Na automação bancária é mais comum encontrar esses drivers escritos em C/C++, e operando em User Mode. No entanto, há uma separação de responsabilidade aqui. O Device Driver tem que conhecer detalhes relativos à comunicação serial ou paralela, e ainda conhecer o protocolo de operação do dispositivo. Esse tipo de preocupação está muito longe do negócio, que é oferecer serviços bancários. E, além disso, por questões de segurança, o protocolo de operação de dispositivos como o dispensador de cédulas é mantido sob segredo por muitos fornecedores. Por isso, normalmente essa camada de software é responsabilidade do fabricante do ATM.

Como cada dispositivo possui uma infinidade de opções de modelos e fornecedores, uma forma de separar essa complexidade da aplicação é por meio de uma camada middleware. Para o autoatendimento em terminais ATM, especialmente para bancos, é muito comum o uso de Service Providers CEN/XFS e Device Services J/XFS, nessa camada middleware. Eu falei um pouco sobre essa camada no artigo Guia para Automação Bancária para iniciantes. Eu também abordei, superficialmente, sobre o desenvolvimento de Service Providers no artigo Desenvolvendo Drivers XFS – Overview. O objetivo dessa camada de software é tentar livrar a aplicação da complexidade que há nessa diversidade que eu citei no paragrafo anterior. CEN/XFS e J/XFS são padrões largamente usados na indústria da automação bancária, e seu objetivo primário é abstrair essa complexidade (embora nem sempre haja sucesso). No entanto, muitas instituições bancárias aqui no Brasil não usam esses padrões. Instituições como o Banco do Brasil, Santander e outros, preferiram projetar sua própria camada Middleware. Nesse caso, essas instituições definem uma especificação, e repassam-na para qualquer fornecedor de ATM que pretenda vender seus equipamentos para ela. Também é comum encontrar instituições que usam um padrão aberto como o CEN/XFS e o J/XFS, e o alteram de acordo com suas necessidades, criando assim extensões para esses padrões. É o caso de instituições como o Itaú, Tecban e outros. Como eu já falei bastante sobre essa camada em artigos anteriores, para este artigo eu vou me concentrar na camada seguinte que é onde se localiza a aplicação.

A aplicação de autoatendimento para terminais ATM ou kiosk pode ser baseada em diversas tecnologias, e projetada com base em diversas estratégias arquitetônicas. Três dessas estratégias são bastante comuns: Fat Client, Thin Client e Hibrido. A estratégia Fat Client é a mais comum e está presente na grande maioria das soluções de autoatendimento das instituições bancárias no Brasil. Nessa estratégia, o software de autoatendimento está hospedado inteiramente no terminal de autoatendimento, fazendo forte uso dos recursos de armazenamento e processamento do terminal. Ou seja, uma solução Fat Client exige mais do hardware (a unidade de microprocessamento – computador) do terminal. Essa estratégia é a mais comum, pois as instituições sempre investiram pesado em seus terminais ATM. A maioria dessas instituições compram, todos os anos, novos ATMs para substituir parte de seu parque, já obsoleto. Ou seja, há um investimento contínuo em hardware, e por isso mesmo, as instituições em geral, preferem preservar esse investimento, e optam por soluções Fat Client. Já a estratégia Thin Client exige mais hardware em servidores e não nos terminais. Esse tipo de solução, na maioria das vezes, é projetado com base em alguma tecnologia Web, com fluxos transacionais, telas e imagens e a maioria dos recursos utilizadas na aplicação ficam hospedados em um servidor na rede. Assim, não há necessidade de muito poder de processamento e armazenamento nos terminais. Esse tipo de estratégia é bastante comum para o autoatendimento de domínios como o de venda de ingressos para cinema e shows, usando os terminais do tipo kiosk. Nesse caso, as unidades de processamento dos terminais normalmente contam com um mini computador (Ex. Raspberry Pi), com baixa capacidade de processamento e armazenamento de dados. Já a solução hibrida procura usar as duas estratégias. Normalmente aqueles serviços mais importantes (Ex.: saque, saldo e deposito e etc) da instituição tem seus recursos mantidos no terminal, e os serviços usados com menos frequência (Ex.: serviço de recarga de celular, publicidade e etc), ou com menos importância para o negócio, ou ainda que sofram alterações com mais frequência, tem seus recursos mantidos no servidor. A estratégia a ser escolhida realmente depende do tipo de negócio, dos recursos de hardware que o cliente já dispõe, e também de questões organizacionais.


Não importa qual a arquitetura da aplicação de autoatendimento. Seja ela qual for o software resultante terá, basicamente, os mesmos módulos mostrados na figura a seguir. Essa é a visão em camadas de uma aplicação de autoatendimento conceitual. São mostrados os componentes típicos de um sistema de autoatendimento para ATM, e como eles se relacionam entre si e sistemas externos encontrados nesses ambientes. Esse tipo de sistema têm, em geral, três tipos de usuários: Cliente, Operador e Gestor. A seguir faço uma descrição básica de cada um desses componentes.


Interface do Cliente é o componente responsável pela camada de apresentação do software para o cliente. Tipicamente, essa camada é construída com base em Java Swing ou seus equivalentes no caso de outras linguagens. No entanto, é comum também encontrar essa camada em construções Flash e HTML5 e, por vezes, uma combinação de todas elas. A tendência atual no meio do autoatendimento é utilizar interfaces cada vez mais interativas, semelhantes àquelas encontradas nos celulares smartphones. Essa tendência têm sido possível em razão da utilização de telas sensíveis ao toque, que simulam o mouse. Assim, o cliente não utiliza mais as teclas laterais para operar a aplicação. Ele toca diretamente em componentes gráficos na tela do terminal, aumentando a interação, e melhorando a experiência do usuário cliente com a aplicação de autoatendimento. Em edições recentes da CIAB, outras tecnologias foram apresentadas, ainda em forma de conceito, para melhorar ainda mais essa experiência do cliente. Uma dessas tecnologias utiliza sensores do tipo kinect que leem os movimentos do cliente, e permitem que a aplicação seja controlada sem a necessidade de tocar na tela do terminal.

Serviços para Cliente é o componente responsável por derivar todos os serviços que estarão disponíveis para o usuário cliente do software. São serviços típicos, o Saque e Depósito em dinheiro ou cheque, bem como extrato de movimentação bancária, transferências de recursos, pagamento de contas entre outros. Para falar de tendências, eu não poderia deixar de citar os movimentos convergentes que têm ocorrido na indústria do autoatendimento bancário. Por meio da convergência entre canais, um novo conjunto de serviços tem sido colocado à disposição do cliente. Os clientes podem iniciar transações de saque no canal Internet Banking e concluí-las nos terminais ATM. Em outras soluções o cliente também pode configurar uma operação de saque no smartphone e transferir esses dados via NFC para o terminal, que dispensará o dinheiro em seguida.

Publicidade é o modulo responsável por receber campanhas e vincular propagandas junto à interface do cliente. Essas campanhas, em geral, são construídas e parametrizadas em sistemas especialistas para os quais esse componente pode ter interface. Aqui a tendência é a utilização de sistemas especialistas cada vez mais inteligentes, que fazem recomendações cada vez mais assertivas para o cliente. O objetivo final de qualquer propaganda, é a venda de um produto. Os sistemas de publicidade são alimentados por informações oriundas de diversos canais da instituição, e quanto mais informação ele puder reunir a respeito do cliente, melhores podem ser suas recomendações e, portanto, as chances de realização de uma venda. Por outro lado, tenho visto soluções de autoatendimento que simplesmente negligenciam esse aspecto do negócio. Já vi aplicação recomendando empréstimo para cliente cujo saldo bancário mostra que ele não precisa disso, e também aplicações mostrando simples mensagem de aguarde, quando poderia estar vinculando uma mensagem publicitária. Acho que aqui, o autoatendimento bancário tem muito ainda por utilizar do conhecimento construído por outros domínios, como o de vendas pela Web, os quais utilizam poderosos sistemas de recomendação.

Monitor é o componente que monitora aspectos como estados dos dispositivos, disponibilidades de serviços e notifica essas informações para sistemas especialistas responsáveis pela monitoração remota dos terminais. Esse módulo é o responsável, por exemplo, por coletar informações que irão definir qual a disponibilidade do terminal em um determinado período. As instituições bancárias mantém contratos de SLA com equipes de manutenção (que as vezes pertencem aos próprios fabricantes dos terminais), e nesse contratos há um número mágico que indica qual é a disponibilidade mínima do terminal durante um período (normalmente um mês). Algumas instituições determinam multas para as equipes ou fabricantes, quando a disponibilidade de seus terminais fica abaixo do que está estipulado nesses contratos. Por isso, esse módulo tem um papel bastante importante na aplicação de autoatendimento.

Periféricos é o componente por meio do qual se tem acesso ao hardware periférico do equipamento. Esse componente é responsável por oferecer uma forma padronizada de acesso a esses periféricos, mesmo diante da diversidade de fabricantes, modelos e infraestrutura disponível no hardware. Bom, isso é o desejável, mas o que se vê muitas vezes em algumas soluções no mercado é uma fraca separação da camada de acesso ao hardware e o restante do negócio da aplicação. Se toda vez que um novo serviço for introduzido na aplicação, o programador tiver que se preocupar em incluir código condicional para cada um dos modelos de terminal, fabricantes e etc, então a manutenção da solução será um caos. Então, o melhor é que haja uma separação clara dos módulos de acesso ao hardware, e que eles abstraiam a complexidade que possa haver nesse hardware, como modelo e fabricante de equipamentos e dispositivos.

Gestor é o componente que controla e gere a operação dos demais componentes da aplicação. Esse componente é responsável por decidir, por exemplo, se a aplicação está em operação ou fora de operação por manutenção, e também por processar comandos remotos enviados por sistemas especialistas de gestão de terminais.

Autorizador é o módulo responsável por estruturar a comunicação com um sistema externo que autoriza as transações. Em geral, todos os serviços disponíveis para o Cliente e o Operador só podem ser acessados mediante processos de autorização, os quais podem ocorrer em diversas etapas. A cada etapa, dados são trocados entre o sistema autorizador e a aplicação de autoatendimento, e uma das responsabilidades do componente em questão é representar esses dados de maneira conveniente para acesso pelos os demais componentes do software.

Serviço para Operador é o componente responsável por derivar todos os serviços que estarão disponíveis para o usuário Operador. São serviços típicos, abastecimento de numerário, configuração do número do terminal ATM, e outros.

Interface do Operador é o componente responsável pela camada de apresentação do software para o operador. Em geral, essa interface é mantida por hardware periférico específico, denominado Painel do Operador. No entanto, em alguns modelos de ATM essa interface é apresentada no mesmo hardware periférico utilizado para a interface do usuário Cliente (ex.: monitor). Quer dizer, em equipamentos dotados de painel do operador, um dispositivo especializado contendo um teclado e um display, é o responsável por prover a interface necessária para o operador operar o terminal a partir da de sua parte traseira. Esse tipo de configuração é típico em ambiente de agencia bancária, onde os terminais ficam posicionados por traz de um drywall, com apenas sua parte frontal sendo exposta aos clientes. Nessa configuração, o operador trabalha na parte de traz do drywall, separado do contato com o cliente, mantendo a segurança da operação e o conforto dos clientes também. Já quando os terminais estão em ambientes de shoppings ou lojas de conveniência, é comum que o terminal fique encostado em uma parede, impedindo sua operação traseira. Nesse tipo de configuração, não há um painel adicional e o operador deverá realizar suas operações por meio da mesma tela e teclado operados pelo cliente.

É isso. Até mais.

domingo, 7 de outubro de 2012

Linhas de Produtos de Software: uma introdução


Olá leitores, 

Hoje abro um novo tipo de artigo no meu blog. São artigos dedicados à Engenharia da Computação. O artigo de estreia é sobre Linhas de Produtos de Software e seu conteúdo é inteiro baseado em um fichamento que estou produzindo para minha Dissertação de Mestrado. O site de origem das informações pode ser acessado aqui: http://www.softwareproductlines.com/

O trabalho do autor se baseia em sua própria experiência de cerca de duas décadas em reuso de software e campos de linhas de produto de software.

O site está organizado na forma de livro online com capítulos de introdução e primeiros passos além de benefícios e casos de sucesso. Ao final são destacados artigos do próprio autor e de pesquisadores voluntários falando sobre as perspectivas da área seguidas de um capítulo de recursos onde podem ser encontradas mais referencias sobre o tema como sites, artigos e livros.

Existem diversas referencias a casos de sucesso de empresas grandes como HP, Phillips e outras.  Nesses casos de sucesso são destacadas melhorias no time-to-market, custo de engenharia, tamanho do portfolio e taxa de defeitos na ordem de 3 para 50. A origem dessa ordem de magnitude é o reuso estratégico de software: consolidar aspectos comuns ao longo da linha de produto, estrategicamente gerenciar toda a variação da linha de produto e agressivamente eliminar toda a duplicação de esforços de engenharia.

Produção em massa – é a habilidade de criar muitas cópias do mesmo produto. Isso representa um avanço enorme no mundo da manufatura, mas é algo trivial para a engenharia de software.
Customização em massa – é a habilidade de eficientemente criar muitas variações de um produto. Esse é um enorme avanço tanto para a manufatura quanto para a engenharia de software e a chave para isso é maximizar os aspectos comuns e eficientemente gerenciar as variações na linha de produto.

Linhas de produto de software podem ser descritos a partir de quatro conceitos:
  1. Ativos de software: requisitos, componentes de software na forma de código fonte, casos de teste, arquitetura e documentação.
  2.  Decisões de produto: descreve características opcionais e variáveis para os produtos na linha de produto. Sua representação pode variar desde descrições informais até descrições formais feitas em linguagem de máquina. O processo de decisão pode também estar associado a papeis como engenheiros de aplicação, engenheiros de domínio, gerente comercial ou cliente.
  3. Mecanismo de produção: meios para a composição e configuração dos ativos de software. Pode ser automatizada, manual ou uma combinação de ambos.
  4. Produto de software: coleção de todos os produtos que podem ser criados a partir da linha de produto.



Cada ativo de software tem um papel bem definido dentro de uma arquitetura comum para a linha de produto. Para que seja possível a variação entre os produtos, alguns desses ativos precisam ser comuns e outros precisam ser passíveis de configuração de modo a proverem diferentes comportamentos. Durante o processo de produção as escolhas para cada uma das características opcionais e variáveis são utilizadas para determinar quais ativos a usar e como configurá-los.


"The characteristic that distinguishes software product lines from previous efforts is predictive versus opportunistic software reuse. Rather than put general software components into a library in hopes that opportunities for reuse will arise, software product lines only call for software artifacts to be created when reuse is predicted in one or more products in a well defined product line."


Os objetivos principais da linha de produtos de software: tirar proveito das características comuns e gerenciar a variação de modo a reduzir tempo, esforço, custo e complexidade na criação e gerenciamento de linha de produto de softwares similares.

A variação presente em alguns dos ativos de software pode ser acessada em alguns momentos especiais durante o processo produtivo. Dentre esses momentos destacam-se:
  1. Código fonte: durante o reuso e configuração de artefatos fonte
  2. Desenvolvimento: durante arquitetura, projeto e codificação.
  3. Instanciação estática do código: durante a montagem do código antes da compilação
  4. Build: durante a compilação
  5. Empacotamento: durante a montagem de coleções binárias e executáveis
  6. Cliente: durante codificação personalizada no cliente
  7. Instalação: durante a instalação do produto de software
  8. Inicialização: durante a inicialização do sistema
  9. Tempo de execução: durante a execução do sistema

Quanto ao escopo existem duas abordagens de gerenciamento do escopo de linha de produtos de software: proativa e reativa. Na abordagem proativa todos os produtos necessários no horizonte previsível são suportados pela linha de produtos. No caso da abordagem reativa somente os produtos necessários imediatamente são suportados pela linha de produto e novos produtos são incrementalmente adicionados à medida que as necessidades mudam. É comum que artefatos como arquitetura tenham um escopo mais proativo do que artefatos como código fonte. 

“strategic software reuse: consolidate commonality throughout the product line, strategically manage all product line variation, and aggressively eliminate all duplication of engineering effort”


Quanto à adoção de linhas de produtos de softwares nas empresas existe diversas abordagem que suportam esse processo. Alguns estudos mostram esforços que variam de 2 meses à 5 anos. Esse esforço é influenciado principalmente pela origem dos ativos de software. A fonte dos ativos de software que mais tarde comporão a linha de produto inclui: artefatos reutilizáveis de uma biblioteca existente, artefatos encapsulados em produtos existentes, ou ainda artefatos desenvolvidos do zero. Enfim, muito tempo pode ser ganho se os ativos forem extraídos de produtos existentes, repositórios existentes e bibliotecas comerciais. No entanto, existem técnicas leves que podem ajudar a diminuir o esforço da adoção de linhas de produtos de software:
  1. Minimizar diferenças entre sistemas únicos e linha de produto
  2. Utilizar uma adoção incremental para inicialmente fazer a transição de um pequeno subconjunto dos ativos, produtos, subsistemas ou pessoas
  3. Oferecer ferramentas e tecnologias de apoio à linha de produtos
  4. Usar abordagens reativas para adiar o desenvolvimento de produtos e esforço de implantação
  5. Estruturar produção para minimizar a necessidade de fusões complexas e custosas

Agora que você tem uma ideia do que é Linha de Produtos de Software resposta a pergunta de pesquisa: Como produzir uma Linha de Produtos de Software usando uma abordagem ágil?

O autoatendimento pode, obviamente, tirar grande vantagem da abordagem usando Linha de Produtos de Softwares. Imagine que uma aplicação de autoatendimento pode ser ela própria uma Linha de Produto e cada serviço que ela disponibiliza é um produto do conjunto. Cada um desses serviços ou produtos podem possuir pontos de personalização ou configuração que permitem mudar o comportamento do produto de modo a, por exemplo, oferecer um serviço de saque com fluxo para cartão de crédito e outro para débito. A própria linha de produto com opções de configuração para execução em equipamentos dotados de telas touch screen ou sem esse recurso e assim por diante. O fato é que essa abordagem permite uma séria de combinações que ao final resultarão em redução dos custos, do tempo de desenvolvimento e na estabilidade geral do produto mediante o reuso expressivo dos artefatos de software.

É isso. Até o próximo artigo!!!

quinta-feira, 29 de setembro de 2011

Desenvolvendo Drivers XFS - Detalhes

Olá leitores. Tenho recebido vários e-mails com pedidos de mais informações de como construir um Service Provider. Há algum tempo, eu publiquei um overview sobre isso (Desenvolvendo Drivers XFS - Overview), mas realmente não passou de um breve resumo. De fato não é uma coisa trivial, e não há muito material disponível. Por isso, vou tentar colocar as informações essenciais (sem muitos detalhes) para guiar o desenvolvimento dos incautos que quiserem tentar construir um Service Provider.

Por motivos econômicos, vou referir-me a Service Provider apenas como SP.

Pré-requisitos para essa peleja
Para conseguir desenvolver satisfatoriamente um SP, é necessário um conhecimento intermediário-avançado sobre threads e desenvolvimento Win32. Além disso, será necessário ter um bom conhecimento sobre o desenvolvimento de DLLs em alguma plataforma de desenvolvimento, como por exemplo: Microsoft Visual C++, Borland C++ Builder ou outra qualquer.

Além disso é necessário ler o documento 1 da especificação CEN/XFS (na versão que se pretende para o SP), e o documento relativo a classe de dispositivo que se pretende desenvolver. Por exemplo, caso se esteja usando a especificação versão 2 de Dezembro de 1998, e o objetivo seja o desenvolvimento para uma impressora, os documentos necessários seriam: CWA13449-1.pdfCWA13449-3.pdf.

Requisitos do SP
Tudo o que é preciso ter em um SP está descrito nos dois documentos da especificação indicados acima. No entanto, a seguir eu relacionou os requisitos chave de qualquer SP:

  1. Exportar as 11 funções WFPXXXXX descritas na especificação: são através dessas funções que se garante a aderência à especificação, por isso elas precisam existir no SP, e precisam também ter um comportamento aderente à especificação;
  2. Funcionamento assíncrono: O SP é assíncrono. Isso é muito importante, mas às vezes passa desapercebido. O ponto é que o protocolo de comunicação entre o SP e o XFS Manager é baseando em regras assíncronas. O XFS Manager é quem permite, artificialmente, que uma aplicação faça chamadas síncronas. Basicamente o que ele faz é aguardar o retorno do atendimento da request por parte do SP antes de retornar a chamada para a aplicação;
  3. Suportar multi-sessões: O SP precisa ser projetado para atender mais de uma aplicação ao mesmo tempo. Isso é muito importante, pois praticamente todos os sistemas de autoatendimento possuem agentes de monitoração que funcionam de modo não integrado à aplicação, e com isso um SP multi-sessão é indispensável;
Arquitetura do SP
Um SP tem, basicamente, duas grandes partes com responsabilidades bem definidas nas quais se concentram os componentes constituintes de qualquer SP:
  1. Estrutura compartilhada: Essa parte do SP é onde se concentra a maior complexidade desse desenvolvimento. Ela é comum a qualquer SP, sem mudanças (se for projetado corretamente).  Em geral, se constrói um ambiente de desenvolvimento de SPs, onde essa parte é compartilhada entre todos os SPs da solução. Mas, essa parte tem tantos componentes críticos que são tão complexos que é muito comum que as empresas e pessoas comprem essa parte pronta de alguma outra empresa que já a tenha construída e debugada (que é o mais importante). Essa parte do desenvolvimento se concentra quase que inteiramente no documento 1 da especificação. Os componentes mais básicos dessa parte são:
    • Gestor de Trace: responsável pela geração de logs do SP. Esse componente pode ser bem simples, onde apenas se escreve o que se quer em um arquivo de log, ou então pode ser bem complexo definindo níveis dos logs que serão gravados, estratégia de rotate, limite de tamanho e etc. Para essa parte, utilizar um framework de mercado como o log4cxx é uma alternativa bem interessante;
    • Gestor de eventos: o SP é basicamente orientado à eventos, ou seja, ele envia e recebe eventos o tempo todo para poder informar que uma operação foi concluída ou que um marco foi alcançado no processamento ou ainda que um limite foi atingido;
    • Agendador de requisições: o SP tem que ser assíncrono conforme os requisitos chaves. Isso quer dizer que qualquer comando que o SP receber deverá ser agendado para execução posterior. Isso é muito importante, pois é preciso prever que um mesmo comando será chamado várias vezes (várias aplicações acessando o SP). Com isso, o agendador precisa implementar uma estratégia de agendamento baseada em fila;
  2. Estrutura específica: Essa parte do SP muda de acordo com a classe de dispositivo e também de acordo com a interface do device driver. Essa é a parte do SP que precisa se comunicar efetivamente com o device driver, que é o controlador do dispositivo. Essa parte pode ser projetada de modo que o comportamento especifico da classe XFS seja resolvido junto com a interface do device driver. No entanto, a solução que mais me agrada é separar as duas coisas; Essa parte do desenvolvimento se concentra inteiramente no documento relativo a classe de dispositivo no qual o SP será construído. Os componentes mais básicos dessa parte são:
    • Interface do Device Driver: este é o ponto de acesso ao dispositivo. Então aqui, em geral, existe uma classe com métodos que dão acesso a funções exportadas em uma dll ou lib do device driver que controla o dispositivo;
    • Implementação da classe de dispositivo XFS: aqui deve ser implementado o comportamento específico da classe de dispositivo XFS de qual trata o SP. Por exemplo, se o SP for para impressora, então a classe de dispositivo é a PTR e deve-se então consultar a especificação dessa classe no conjunto de documentos XFS. No caso da impressora o documento é CWA13449-3.pdf;

Codificação
Aqui a dica é criar um projeto de DLL. Essa DLL precisa exportar as 11 funções previstas na especificação, e toda vez que essas funções forem executadas, uma sequencia de acontecimento deve ocorrer no interior do SP. Basicamente a sequencia é a seguinte:
  1. Verificar informações básicas a cerca dos parâmetros recebidos e também o estado em que se encontra a sessão. Por exemplo, um WFSExecute só pode ser executado após um WFSOpen. Ainda, se for executado um WFSLock, somente a aplicação que possui o "lock" poderá executar WFSExecute. As demais aplicações que não possuírem o "lock" poderão apenas consultar informações, executando, por exemplo WFSGetInfo;
  2. Agendar o processamento dessa "solicitação", armazenando todos os parâmetros da chamada em uma fila;
  3. Retornar WFS_SUCCESS para a chamada da função. Obviamente esse retorno significa apenas: "Ok, tudo certo até aqui, eu posso processar sua requisição...". Caso não seja esse o caso, precisa então ser retornado um código de erro que melhor indique o motivo pelo qual a solicitação não pôde ser atendida;
  4. Assim que possível, retirar solicitações da fila, analisar seus parâmetros e processa-los de acordo com a especificação para aquela classe de dispositivo. O resultado do processamento é SEMPRE um evento. Ou seja, mesmo que o resultado do processamento seja um erro, um evento deve ser gerado para o XFS Manager, informando-o desse resultado. Esse evento nada mais é do que uma mensagem windows, direcionada para o handle indicado nos parâmetros da chamada. Claro que isso aqui é uma aproximação simplista. De fato, existem mais questões envolvidas aqui como: verificar se não foi atingido o timeout para execução da solicitação, lançar eventos intermediários, notificar aplicações ouvintes que se registram para receber certo tipos de eventos e etc;

Testes
Bom, para testar o SP é necessário uma aplicação XFS para a classe de dispositivo em questão. Essa parte é bem mais fácil, e é possível construir rapidamente essa aplicação de testes. A aplicação pode ser inclusive construída para operar com uma interface de linha de comando. Para fazer essa construção basta utilizar o documento 1 da especificação, buscando informações sobre as funções WFSXXXX contidas no capitulo 4 (Application Programming Interface (API) Functions). A sequência básica de comandos para uma aplicação XFS é a seguinte:
  1. WFSStartUp;
  2. WFSOpen;
A partir daí, é possível executar os comandos específicos da classe utilizando os comandos WFSExecute e WFSGetInfo.


É isso. Té mais!!!



segunda-feira, 1 de agosto de 2011

O futuro do ATM

Olá leitores. Hoje vou falar um pouco sobre as tendências relacionadas ao uso do ATM, em face da grande disseminação dos serviços bancários através de dispositivos Web (smartphones, TVs e etc), e também do dinheiro de plástico (cartões de débito, crédito, benefícios e etc).

O primeiro ATM parecido com o que usamos hoje foi criado pela IBM em 1972. Desde essa época, o ATM tem ganho novas funcionalidades e serviços o que contribuiu para sua expansão até aqui. O ATM levou a agência bancária para outras localidades: para dentro do shopping, para a esquina das ruas e até para pequenos comércios e postos de gasolina. Enfim, o ATM se tornou indispensável para nossas vidas como a conhecemos, e é dificil pensar em algo mais cômodo do que essa elegante solução tecnologica. Será?

Precursor do ATM, inventado por Luther George Simjian e apresentado ao público em 1961.


Estamos vivendo um momento muito excitante de fato, com várias tecnologias convergindo, e a Web 2.0 dirigindo a segunda grande onda da Internet, onde praticamente qualquer dispositivo eletronico, desde TVs, smartphones, passando até por microondas e geladeiras, saem de fábrica com a capacidade de nos colocar on-line com milhões de outros usuários no mundo. 

O Internet Banking não poderia deixar de se beneficiar dessa oportunidade de aumentar sua penetração, e é isso o que de fato está ocorrendo. No meu ultimo post (CIAB 2011) eu mostrei um gráfico da Febraban que mostra como vem aumentando o uso do Internet Banking. Seu crescimento tem sido muito grande, e é provavel que dentro de poucos anos seu uso supere o uso dos ATMs, mostrando então a importancia desse canal para os bancos, e apontando também para onde esses devem direcionar seus investimentos nos próximos anos. Isso é um fato, praticamente todos os bancos além de manter seu Internet Banking bem atualizado, também mantém uma versão para smartphones e tablets (chamado tecnicamente de Mobile Banking), e bancos como o Bradesco agora trazem versões de seu Internet Banking para as TVs Inteligentes que têm invadido o mercado.



Ainda na onda da comodidade máxima, outros meios de pagamento tem enorme destaque, e com importância cada vez mais crescente. Os cartões como forma de pagamento estão presentes de diversas formas em nossa vida: crédito, débito, alimentação, refeição, transporte e etc. Junto com o cheque, todas essas formas do dinheiro diminuem a necessidade de se andar com "dinheiro real" no bolso. Afinal, todos eles são uma substituição ao dinheiro em sua forma física mais tradicional (cédulas e moedas).


E ainda tem mais. Mobile Payment, que é o uso do celular para realizar pagamentos. Essa modalidade tem ganho cada vez mais importância, e os principais empresários do setor de meios de pagamento acreditam que Mobile Payment será amplamente usado dentro dos próximos 4 anos.

Isso tudo estabelece o contexto no qual eu defini o título deste post. Qual é o futuro do ATM afinal, considerando que tudo aponta para uma perspectiva na qual o uso do dinheiro em espécie perderá cada vez mais a importância? Afinal, sacar dinheiro é um dos poucos serviços que não é possível de ser realizado via Internet Banking, da comodidade de sua poltrona na sala de estar.

Novos rumos para o ATM
 É dificil prever quando o ATM perderá efetivamente o seu papel atual como repositor do nosso dinheiro guardado pelos bancos, mas é provavel que isso ocorrar a partir do momento em que não mais precisarmos usá-lo em espécie. O ponto é que ainda hoje boa parte da população recebe seu salário em espécie, e o pagamento em espécie é ainda o grande preferido da maioria esmagadora da população. Com isso, o ATM ainda tem uma boa sobrevida com seus serviços atuais ligados ao saque e depósito de dinheiro ou cheque.

Além disso, comparando com o mundo, há um amplo espaço de crescimento do número de ATMs aqui no Brasil. A densidade de ATMs por milhões de pessoas aqui é cerca de 700 ATMs por milhão de pessoas enquanto nos Estados Unidos esse número é cerca de 1400.

O que parece razoável que ocorra é um aproveitamento melhor da base instalada de ATMs, para servir a população com uma variedade maior de serviços como:
  1. Pagamento de contas em qualquer ATM de qualquer banco. Essa é uma funcionalidade típica de correspondente bancário, e embora existam algumas dificuldades técnicas, essa é uma funcionalidade possível de ser implantada;
  2. Recarga do Bilhete Único e similares;
  3. Compra de ingressos para cinema e teatro;
  4. etc.
Os maiores entraves tecnologicos para a ampliação da oferta de serviços nos ATMs, principalmente, multi-instituições, está ligado a problemas de integração.

Maior Interatividade
O que parece ser ainda mais provável é o aumento da interatividade das aplicações de autoatendimento. Aplicações Web (baseadas em Browser), já são uma realidade e a tendência é que se aumente o uso desse tipo de aplicação, para poder usar recursos avançados de interatividade oferecidos por tecnologias Web como HTM5, CSS, Javascript e etc. Abaixo segue um vídeo do YouTube, de autoria do BBVA do México, mostrando um exemplo de como a aplicação de autoatendimento poderia ser mais interativa, e até mesmo o hardware do ATM com bastante mudanças interessantes. Tivemos algo bem parecido com isso também na CIAB deste ano:


É isso :)