Ola leitores. Tenho recebido varios e-mails com pedidos de mais informacoes de como construir um Service Provider. Ha algum tempo, eu publiquei um overview sobre isso (Desenvolvendo Drivers XFS - Overview), mas realmente nao passou de um breve resumo. De fato nao e uma coisa trivial, e nao ha muito material disponivel. Por isso, vou tentar colocar as informacoes essenciais (sem muitos detalhes) para guiar o desenvolvimento dos incautos que quiserem tentar construir um Service Provider.Por motivos economicos, vou referir-me a Service Provider apenas como SP.Pre-requisitos para essa pelejaPara conseguir desenvolver satisfatoriamente um SP, e necessario um conhecimento intermediario-avancado sobre threads e desenvolvimento Win32. Alem disso, sera necessario 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.Alem disso e necessario ler o documento 1 da especificacao CEN/XFS (na versao 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 especificacao versao 2 de Dezembro de 1998, e o objetivo seja o desenvolvimento para uma impressora, os documentos necessarios seriam: CWA13449-1.pdf e CWA13449-3.pdf.Requisitos do SPTudo o que e preciso ter em um SP esta descrito nos dois documentos da especificacao indicados acima. No entanto, a seguir eu relacionou os requisitos chave de qualquer SP:Exportar as 11 funcoes WFPXXXXX descritas na especificacao: sao atraves dessas funcoes que se garante a aderencia a especificacao, por isso elas precisam existir no SP, e precisam tambem ter um comportamento aderente a especificacao;Funcionamento assincrono: O SP e assincrono. Isso e muito importante, mas as vezes passa desapercebido. O ponto e que o protocolo de comunicacao entre o SP e o XFS Manager e baseando em regras assincronas. O XFS Manager e quem permite, artificialmente, que uma aplicacao faca chamadas sincronas. Basicamente o que ele faz e aguardar o retorno do atendimento da request por parte do SP antes de retornar a chamada para a aplicacao;Suportar multi-sessoes: O SP precisa ser projetado para atender mais de uma aplicacao ao mesmo tempo. Isso e muito importante, pois praticamente todos os sistemas de autoatendimento possuem agentes de monitoracao que funcionam de modo nao integrado a aplicacao, e com isso um SP multi-sessao e indispensavel;Arquitetura do SPUm SP tem, basicamente, duas grandes partes com responsabilidades bem definidas nas quais se concentram os componentes constituintes de qualquer SP:Estrutura compartilhada: Essa parte do SP e onde se concentra a maior complexidade desse desenvolvimento. Ela e comum a qualquer SP, sem mudancas (se for projetado corretamente). Em geral, se constroi um ambiente de desenvolvimento de SPs, onde essa parte e compartilhada entre todos os SPs da solucao. Mas, essa parte tem tantos componentes criticos que sao tao complexos que e muito comum que as empresas e pessoas comprem essa parte pronta de alguma outra empresa que ja a tenha construida e debugada (que e o mais importante). Essa parte do desenvolvimento se concentra quase que inteiramente no documento 1 da especificacao. Os componentes mais basicos dessa parte sao:Gestor de Trace: responsavel pela geracao