No meio do Azure estão os .Net Services, que são uma série de serviços disponibilizados pela Microsoft na Nuvem. Na prática: Workflow, Service Bus e Access Control Services. Para saber mais recomendo o excelente post do Waldemir Cambiucci sobre o assunto.
Se você já leu ou já sabe o que é, então vou mostrar um pouco do que você pode fazer com o .Net Service Bus (NSB) neste post e no próximo. O NSB se propõe a ser um barramento entre uma ou mais aplicações, controlando e distribuindo o fluxo de informação. Ele se propõe a aplicar, inclusive, autenticação e autorização com ajuda do Access Control Services (que é um dos 3 serviços do .Net Services).
O diagrama abaixo, tirado da palestra de .Net Services do último PDC, mostra o que é possível fazer. Você possui uma aplicação que envia um dado, que bate em um endpoint, e vai parar no receptor, que fica esperando a mensagem. A comunicação pode passar sempre pelo servidor da Microsoft na Nuvem (aparecendo em flechas vermelhas), como também se conectar diretamente com o destino (mostrado em verde). Neste caso, a comunicação inicial passa pelo servidor da Microsoft e depois segue para a comunicação direta se ela estiver disponível (por isso a linha verde pontilhada).
Também é possível realizar uma comunicação do estilo publisher/subscriber, ou seja, publicador e assinante, mais conhecida como multicast. Neste caso a mensagem segue para a nuvem, e é distribuída para todos os assinantes. E você pode ainda ter mais de um publisher:
Achei esse recurso de Multicast é especialmente interessante, porque permite usar a infra-estrutura do Azure para fazer envios massivos de dados via web, sem se preocupar com a quantidade de assinantes.
Tudo isso é complicadíssimo de fazer. Não, mentira. É muito fácil. Chega a ser ridículo de tão fácil. Vou mostrar no próximo post como montar uma aplicação simples que manda dados, e vou explicar o que está acontecendo. E já adianto: se você conhece WCF, programar para o NSB é muito simples, porque os caras não reinventaram a roda, toda a codificação está sendo feita sobre o WCF, somente com a adição de novos tipos de binding. E como tudo é baseado em WCF (de longe a melhor tecnologia para distribuição de computação), você pode utilizar (e trocar de) protocolos com facilidade, usando TCP, HTTP. Há também suporte total para padrões como WS*, REST, SOAP, Atom, etc. Isso permite acesso a qualquer linguagem. Não bastasse isso a Microsoft está preparando bibliotecas de classes de conexão a todo o .Net Services não só para .Net, mas também para Java, PHP, Ruby, etc…
A parte de controle de acessos também ficou bem legal, e tenho certeza que será um motivo importantíssimo para a adoção, pelas capacidades de federação, que estão ficando muito facilitadas. Mas isso é assunto para outro post.
Em tempo: você vai precisar do SDK para desenvolver com .NET Services. Nesse momento, o último SDK é o de dezembro de 2008. E tudo funciona perfeitamente, sem bugs, nem parece CTP. Você vai precisar de uma conta do CTP para acessar, portanto mexa-se se você ainda não tem uma, porque elas demoram a chegar.
Giovanni Bassi
Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.