Como construir um 'Service Provider'

Ol leitores. Tenho recebido vrios e-mails com pedidos de mais informaes de como construir um Service Provider. H algum tempo, eu publiquei um overview sobre isso (Desenvolvendo Drivers XF - Overview), mas realmente no passou de um breve resumo. De fato no uma coisa trivial, e no h muito material disponvel. Por isso, vou tentar colocar as informaes essenciais (sem muitos detalhes) para guiar o desenvolvimento dos incautos que quiserem tentar construir um Service Provider. Por motivos econmicos, vou referir-me a Service Provider apenas como SP. Pr-requisitos para essa peleja Para conseguir desenvolver satisfatoriamente um SP, necessrio um conhecimento intermedirio-avanado sobre threads e desenvolvimento Win32. Alm disso, ser necessrio 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. Alm disso necessrio ler o documento 1 da especificao CEN/XFS (na verso 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 especificao verso 2 de Dezembro de 1998, e o objetivo seja o desenvolvimento para uma impressora, os documentos necessrios seriam: CWA13449-1.pdf e CWA13449-3.pdf. Requisitos do SP Tudo o que preciso ter em um SP est descrito nos dois documentos da especificao indicados acima. No entanto, a seguir eu relacionou os requisitos chave de qualquer SP: 1. Exportar as 11 funes WFPXXXXX descritas na especificao: so atravs dessas funes que se garante a aderncia especificao, por isso elas precisam existir no SP, e precisam tambm ter um comportamento aderente especificao; 2. Funcionamento assncrono: O SP assncrono. Isso muito importante, mas s vezes passa desapercebido. O ponto que o protocolo de comunicao entre o SP e o XFS Manager baseando em regras assncronas. O XFS Manager quem permite, artificialmente, que uma aplicao faa chamadas sncronas. Basicamente o que ele faz aguardar o retorno do atendimento da request por parte do SP antes de retornar a chamada para a aplicao;

3. Suportar multi-sesses: O SP precisa ser projetado para atender mais de uma aplicao ao mesmo tempo. Isso muito importante, pois praticamente todos os sistemas de autoatendimento possuem agentes de monitorao que funcionam de modo no integrado aplicao, e com isso um SP multi-sesso indispensvel; 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 mudanas (se for projetado corretamente). Em geral, se constri um ambiente de desenvolvimento de SPs, onde essa parte compartilhada entre todos os SPs da soluo. Mas, essa parte tem tantos componentes crticos que so to complexos que muito comum que as empresas e pessoas comprem essa parte pronta de alguma outra empresa que j a tenha construda e debugada (que o mais importante). Essa parte do desenvolvimento se concentra quase que inteiramente no documento 1 da especificao. Os componentes mais bsicos dessa parte so: o Gestor de Trace: responsvel pela gerao de logs do SP. Esse componente pode ser bem simples, onde apenas se escreve o que se quer em um arquivo de log, ou ento pode ser bem complexo definindo nveis dos logs que sero gravados, estratgia de rotate, limite de tamanho e etc. Para essa parte, utilizar um framework de mercado como o log4cxx uma alternativa bem interessante; o Gestor de eventos: o SP basicamente orientado eventos, ou seja, ele envia e recebe eventos o tempo todo para poder informar que uma operao foi concluda ou que um marco foi alcanado no processamento ou ainda que um limite foi atingido; o Agendador de requisies: o SP tem que ser assncrono conforme os requisitos chaves. Isso quer dizer que qualquer comando que o SP receber dever ser agendado para execuo posterior. Isso muito importante, pois preciso prever que um mesmo comando ser chamado vrias vezes (vrias aplicaes acessando o SP). Com isso, o agendador precisa implementar uma estratgia de agendamento baseada em fila; 2. Estrutura especfica: Essa parte do SP muda de acordo com a classe de dispositivo e tambm 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 soluo 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 construdo. Os componentes mais bsicos dessa parte so: o Interface do Device Driver: este o ponto de acesso ao dispositivo. Ento aqui, em geral, existe uma classe com mtodos que do acesso a funes exportadas em uma dll ou lib do device driver que controla o dispositivo; o Implementao da classe de dispositivo XFS: aqui deve ser implementado o comportamento especfico da classe de dispositivo XFS de qual trata o SP. Por exemplo, se o SP for para impressora, ento a classe de dispositivo a PTR e deve-se ento consultar a especificao dessa classe no conjunto de documentos XFS. No caso da impressora o documento CWA13449-3.pdf; Codificao Aqui a dica criar um projeto de DLL. Essa DLL precisa exportar as 11 funes previstas na especificao, e toda vez que essas funes forem executadas, uma sequencia de acontecimento deve ocorrer no interior do SP. Basicamente a sequencia a seguinte: 1. Verificar informaes bsicas a cerca dos parmetros recebidos e tambm o estado em que se encontra a sesso. Por exemplo, um WFSExecute s pode ser executado aps um WFSOpen. Ainda, se for executado um WFSLock, somente a aplicao que possui o "lock" poder executar WFSExecute. As demais aplicaes que no possurem o "lock" podero apenas consultar informaes, executando, por exemplo WFSGetInfo; 2. Agendar o processamento dessa "solicitao", armazenando todos os parmetros da chamada em uma fila; 3. Retornar WFS_SUCCESS para a chamada da funo. Obviamente esse retorno significa apenas: "Ok, tudo certo at aqui, eu posso processar sua requisio...". Caso no seja esse o caso, precisa ento ser retornado um cdigo de erro que melhor indique o motivo pelo qual a solicitao no pde ser atendida; 4. Assim que possvel, retirar solicitaes da fila, analisar seus parmetros e processa-los de acordo com a especificao 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 parmetros da chamada. Claro que isso aqui

 uma aproximao simplista. De fato, existem mais questes envolvidas aqui como: verificar se no foi atingido o timeout para execuo da solicitao, lanar eventos intermedirios, notificar aplicaes ouvintes que se registram para receber certo tipos de eventos e etc; Testes Bom, para testar o SP necessrio uma aplicao XFS para a classe de dispositivo em questo. Essa parte bem mais fcil, e possvel construir rapidamente essa aplicao de testes. A aplicao pode ser inclusive construda para operar com uma interface de linha de comando. Para fazer essa construo basta utilizar o documento 1 da especificao, buscando informaes sobre as funes WFSXXXX contidas no capitulo 4 (Application Programming Interface (API) Functions). A sequncia bsica de comandos para uma aplicao XFS a seguinte: 1. WFSStartUp; 2. WFSOpen; A partir da, possvel executar os comandos especficos da classe utilizando os comandos WFSExecute e WFSGetInfo.

isso. T mais!!!

Autor
Meu nome Fagner Souza, sou especialista em automao bancria e comercial com larga experincia em sistemas de Autoatendimento. Meu website http://www.fagnersouza.com.br e nele voc pode encontrar meus contatos.