an introduction to microsoft .net services for...
TRANSCRIPT
Introdução ao Microsoft® .NET Services para Desenvolvedores
.NET Framework na nuvem
Aaron Skonnard, Pluralsight
Maio de 2009
Todas as informações e exemplos de código se baseiam na versão CTP do .NET Services de Março de 2009.
Conteúdo
Resumo................................................................................................................................................4
Visão Geral da Plataforma de Serviços Azure........................................................................................4
Windows® Azure™...................................................................................................................................5
Microsoft® .NET Services.........................................................................................................................5
Microsoft® SQL Services..........................................................................................................................6
Serviços Adicionais..................................................................................................................................7
Construindo a partir da Plataforma de Serviços Azure™.........................................................................7
Apresentando o Microsoft® .NET Services............................................................................................8
Visão Geral do .NET Services...................................................................................................................8
Introdução ao Uso do .NET Services........................................................................................................9
Criando Sua Primeira Solução................................................................................................................12
Gerenciando as Credenciais da Solução................................................................................................15
Exemplos no SDK do .NET Services........................................................................................................15
Barramento de Serviços Microsoft® .NET............................................................................................16
Conectividade Retransmitida.................................................................................................................17
Conectividade Direta.............................................................................................................................18
Endereços de Retransmissão e Controle de Acesso..............................................................................19
Registro de Serviços...............................................................................................................................20
Filas e Roteadores.................................................................................................................................20
Integração com o WCF...........................................................................................................................22
Exemplo Simples Baseado no Barramento de Serviços .NET.................................................................23
Serviço de Controle de Acesso Microsoft®.NET...................................................................................28
Identidade Baseada em Declarações.....................................................................................................28
Benefícios do Logon Único....................................................................................................................29
Portal de Administração........................................................................................................................29
Exemplo Simples Baseado no Serviço de Controle de Acesso .NET.......................................................30
Serviço de Fluxo de Trabalho Microsoft®............................................................................................35
Host de Fluxo de Trabalho Baseado na Nuvem.....................................................................................36
Hospedagem e Persistência na Nuvem..................................................................................................36
Projetando Fluxos de Trabalho para a Nuvem.......................................................................................37
Atividades na Nuvem.............................................................................................................................37
Exemplo Simples Baseado no Serviço de Fluxo de Trabalho .NET.........................................................38
Juntando Tudo...................................................................................................................................42
Sumário.............................................................................................................................................43
Recursos Adicionais............................................................................................................................44
Série de Whitepapers do Microsoft® .NET Services...............................................................................44
Recursos do Microsoft® .NET Services...................................................................................................44
Sobre o Autor.....................................................................................................................................44
Agradecimentos.................................................................................................................................45
Resumo
Este documento é o primeiro de uma série dedicada ao Microsoft® .NET Services, parte essencial da Plataforma de Serviços Azure™. O Microsoft® .NET Services possui um conjunto de blocos de construção usados normalmente por desenvolvedores em aplicações baseadas na nuvem e com reconhecimento da nuvem. Este documento apresenta o Microsoft® .NET Services, cada um de seus serviços de bloco de construção e o modo como eles se integram. Para obter uma explicação mais detalhada de cada serviço, leia os outros artigos desta série (consulte a seção Recursos Adicionais).
Visão Geral da Plataforma de Serviços Azure
A Plataforma de Serviços Azure™ foi preparada para mudar radicalmente o modo como os arquitetos e desenvolvedores da Microsoft realizam a construção e o gerenciamento das aplicações. A Plataforma de Serviços Azure™ (veja a Figura 1) oferece um ambiente de computação em nuvem baseado na Internet para a execução de aplicações e o armazenamento de dados nos data centers da Microsoft em todo o mundo. Sob vários aspectos, você pode pensar nela como o Windows® na nuvem.
Figura 1: Plataforma de Serviços Azure
A Plataforma de Serviços Azure™ é formada pelo sistema operacional de nuvem Windows®Azure™ como base e por vários serviços de bloco de construção em camadas, como mostra a Figura 1. Você pode utilizar essa nova plataforma de computação em nuvem da Microsoft para hospedar novas aplicações ou serviços individuais e, assim, aumentar o retorno dos investimentos já feitos em softwares no local (on-premises). A escolha é sua.
Windows® Azure™
O Windows®Azure™ possui uma malha de computação em nuvem hospedada nos data centers da Microsoft. Essa malha serve para criar, implantar, gerenciar e distribuir (escalar) aplicações e serviços na Internet. O Windows®Azure™ oferece duas áreas de funcionalidade: computação (execução de uma aplicação, por exemplo) e armazenamento (de dados em um disco, por exemplo). A vantagem está em como o Windows® Azure™ fornece esses recursos fundamentais praticamente sem restrições. A escalabilidade horizontal é apenas uma questão de configuração. Do ponto de vista corporativo, o Windows® Azure™ pode livrá-lo do trabalho e do custo gerados pela complexidade de TI relacionada ao provisionamento, à configuração e ao gerenciamento de servidores físicos e dos softwares executados neles.
É importante ressaltar que os serviços de armazenamento do Windows® Azure™ são simples e altamente escaláveis. Ele oferece serviços essenciais para armazenamento em BLOB, armazenamento em fila e armazenamento em tabelas simples, mas não possui os recursos de um banco de dados relacional (consulta, pesquisa, relatório e análise, por exemplo). Se você precisar desses recursos relacionais mais avançados utilize o Microsoft® SQL Services.
Como mostra a Figura 1, há vários serviços executados na estrutura básica do Windows® Azure™, tais como Microsoft® .NET Services, Live Services, Microsoft® SQL Services, entre outros. Embora o enfoque deste documento seja especificamente o Microsoft® .NET Services, vale à pena descrever com mais detalhes cada um desses serviços e como eles se complementam dentro da Plataforma de Serviços Azure™.
Microsoft® .NET Services
O Microsoft® .NET Services oferece um conjunto de serviços voltados ao desenvolvedor .NET e um SDK (software development kit) para a construção das aplicações .NET que serão executadas na nuvem. No momento, sua funcionalidade está relacionada principalmente à conectividade das aplicações, ao controle de acesso e à hospedagem de fluxos de trabalho.1 Os três serviços fornecidos por ele são: Barramento de Serviços Microsoft® .NET, Serviço de Controle de Acesso Microsoft® .NET e Serviço de Fluxo de Trabalho Microsoft® .NET. Sob alguns aspectos, podemos pensar no Microsoft® .NET Services como o novo .NET Framework que usaremos para construir aplicações na nuvem, mas se trata de uma malha de desenvolvimento inteiramente baseada em serviços.
O nome Microsoft® .NET Services se deve, entre outras coisas, ao fato de ele ter sido projetado e otimizado para fornecer uma experiência de primeira classe ao desenvolvedor .NET. Com o SDK do Microsoft® .NET Services, trabalhar com esses serviços baseados na nuvem é como escrever qualquer outra aplicação .NET. O SDK permite a integração ao Windows Communication Foundation (WCF) e ao Windows Workflow Foundation (WF), portanto o desenvolvedor .NET pode aperfeiçoar suas habilidades
1 É provável que a funcionalidade do Microsoft® .NET Services cresça e, futuramente, inclua ainda mais recursos do .NET Framework na nuvem.
nessas áreas. No final das contas, o Microsoft® .NET Services proporciona uma experiência de desenvolvimento centrada em .NET durante a construção de aplicações para a nuvem.
Embora o Microsoft® .NET Services tenha sido projetado para aprimorar a experiência do desenvolvedor .NET, vale destacar que, como ele é baseado em protocolos padrão da indústria, qualquer plataforma de serviços pode se integrar a ele por meio das técnicas REST, SOAP e WS-* padrão. Já estão disponíveis para download, por exemplo, SDKs do Microsoft® .NET Services para Java e Ruby.
Microsoft® SQL Services
O Microsoft® SQL Services oferece um conjunto de serviços orientados a dados que foram projetados para estender os recursos do SQL Server para a nuvem, como parte da Plataforma de Serviços Azure™. Microsoft® SQL Services é, na verdade, a marca comercial da família de serviços relacionados ao SQL. O primeiro serviço incluído nessa marca é o Microsoft® SQL Data Services (SDS), que contribui para a formação da Plataforma de Serviços Azure™ com uma oferta completa de recursos característicos dos bancos de dados relacionais. É provável que sejam incluídos outros serviços centrados em dados futuramente.
O SDS fornece todos os recursos de um banco de dados relacional, mas na forma de um serviço executado na nuvem. Isso inclui tabelas, procedimentos armazenados, gatilhos, visões, índices e compatibilidade com Visual Studio .NET, ADO.NET e ODBC. Os desenvolvedores poderão provisionar servidores lógicos e instâncias de banco de dados na nuvem e começar a trabalhar com eles usando as mesmas ferramentas e tecnologias que utilizam hoje. Isso é possível porque o Microsoft® SQL Services tem suporte para o protocolo Tabular Data Stream (TDS), o mesmo usado pelo SQL Server executado no local (on-premises). Assim, os desenvolvedores poderão usar qualquer ferramenta ou tecnologia compatível com TDS quando trabalharem com suas instâncias do Microsoft® SQL Services executadas na nuvem. A maioria deles só terá que atualizar suas cadeias de conexão para apontar para os bancos de dados do Microsoft® SQL Services.
O Live Services possui um conjunto de serviços centrados no usuário, com enfoque nas aplicações e experiências sociais, junto com uma estrutura que facilita a programação. Mais especificamente, a marca Live Services inclui os Serviços de Malha (Mesh Services), os Serviços de Identidade (Identity Services), os Serviços de Diretório (Directory Services), os Serviços de Armazenamento de Dados do Usuário (User-Data Storage Services), os Serviços de Comunicação e Presença (Communication and Presence Services), os Serviços de Busca (Search Services) e os Serviços Geoespaciais (Geospatial Services).
O Live Framework fornece uma estrutura de desenvolvimento baseada em padrões para interagir com todos esses serviços através de um protocolo/interface consistente. O Live Framework inclui REST, Atom e AtomPub, permitindo assim a integração de qualquer usuário ao Live Services, por meio de técnicas de programação HTTP/XML comuns. Ele também vem com um SDK cliente amigável para desenvolvedores .NET e um tempo de execução de cliente rico que oferece recursos de sincronização de malha embutidos, bem como suporte online e offline.
Finalmente, com o Live Services é possível construir aplicações mashup ricas que utilizam os dados encontrados na plataforma Windows Live, usada por mais de 400 milhões de pessoas atualmente, permitindo uma sincronização avançada dos dados entre dispositivos, aplicações e parceiros corporativos.
Serviços Adicionais
Além desses serviços básicos (.NET, SQL e Live), a Microsoft também está trabalhando em alguns serviços específicos para cada domínio. Uma dessas ofertas, o Microsoft® SharePoint Services, fornecerá uma série de serviços de bloco de construção do SharePoint que você pode incorporar em suas próprias aplicações. Outro exemplo é o Microsoft® Dynamics CRM Services, um conjunto de serviços de bloco de construção do Microsoft® Dynamics CRM hospedados na nuvem. Em ambos os casos, os desenvolvedores continuarão escrevendo o código no Visual Studio e terão a lógica resultante hospedada na Plataforma de Serviços Azure™. As duas tecnologias ainda estão em processo de construção, portanto fique atento ao lançamento da versão CTP inicial de cada uma delas.
É importante entender que o Microsoft® SharePoint Services e o Microsoft® Dynamics CRM Services são ofertas de serviço; não são aplicações de usuário final. Os recursos oferecidos por eles, em suas respectivas áreas, podem ser incorporados às aplicações dos desenvolvedores.
Construindo a partir da Plataforma de Serviços Azure™
A Plataforma de Serviços Azure™ é, essencialmente, a plataforma que serve de base para que o desenvolvedor construa sua aplicação. Um dos aspectos mais práticos da Plataforma de Serviços Azure™ é o fato de seu projeto levar em conta as habilidades que os desenvolvedores da Microsoft já têm. Os desenvolvedores que escrevem códigos para a Plataforma de Serviços Azure™ podem escrever códigos .NET tradicionais usando o Visual Studio, além de utilizarem a experiência que possuem em Windows Communication Foundation, Windows Workflow Foundation, Windows SharePoint, Windows Live e SQL Server.
Se você é um desenvolvedor do Microsoft .NET, a experiência no Azure™ parecerá bastante familiar. As diferenças giram em torno de como devemos implantar, hospedar, escalar e gerenciar os novos softwares baseados na nuvem. A Plataforma de Serviços Azure™ utiliza como base o ecossistema .NET já existente, o que proporciona à Microsoft uma forte vantagem sobre a concorrência na área de computação em nuvem.
Se você estiver construindo uma aplicação abrangente na nuvem com base na Plataforma de Serviços Azure™, provavelmente utilizará vários dos serviços descritos acima, se não todos. Você pode usar o Microsoft® .NET Services para ter conectividade e segurança, o Microsoft® SQL Services no armazenamento e na recuperação de dados e os recursos de sincronização de malha do Live Services. É extremamente valioso o modo como essas diferentes tecnologias podem ser unidas na criação de aplicações completas. A Figura 2 exibe detalhes da Plataforma de Serviços Azure™ e dos serviços que apresentamos.
Figura 2: Visão Detalhada da Plataforma de Serviços Azure
A própria Microsoft tem estado ocupada com a construção de aplicações de usuário final que utilizam esses serviços na Plataforma de Serviços Azure™. Essas aplicações incluem o Windows Live, o Microsoft® Office Live, o Microsoft® Exchange Online, o Microsoft® SharePoint Online e o Microsoft® Dynamics CRM Online (veja novamente a Figura 1) . São exemplos de aplicações de usuário final projetadas para uso imediato.
Como você pode ver, a Microsoft está investindo na computação em nuvem com uma estratégia abrangente, que facilitará a participação dos desenvolvedores .NET nessa nova era do desenvolvimento de softwares.
Apresentando o Microsoft® .NET Services
O desenvolvedor do Microsoft .NET que pretende trabalhar com a Plataforma de Serviços Azure™ deve reservar o tempo necessário para se familiarizar com o Microsoft® .NET Services, que chamarei apenas de “.NET Services” de agora em diante. A razão é simples: o .NET Services oferece os principais blocos de construção que você necessitará para construir aplicações baseadas na nuvem e com reconhecimento de nuvem na Plataforma de Serviços Azure™. No restante deste documento, vamos nos aprofundar nos serviços do .NET Services mostrados na Figura 2.
Visão Geral do .NET Services
Os serviços incluídos na marca .NET Services formam uma infraestrutura valiosa que facilitará o trabalho de construção de aplicações na nuvem.
As funcionalidades básicas do .NET Services estão relacionadas à conectividade de aplicações, ao controle de acesso e à orquestração de mensagens baseada em fluxo de trabalho. Com o tempo, sua infraestrutura será mais completa e serão oferecidos outros recursos baseados na nuvem. No momento, a marca .NET Services inclui os seguintes blocos de construção:
Barramento de Serviços Microsoft® .NET : oferece uma infraestrutura de rede que conecta as aplicações através da Internet usando diversos padrões de sistema de mensagens. Ele consegue atravessar firewalls e dispositivos NAT sem prejudicar a segurança proporcionada por eles.
Serviço de Controle de Acesso Microsoft® .NET : proporciona um controle de acesso baseado em declarações na nuvem. Inclui um mecanismo de transformação de declarações que faz federação de identidade com provedores como Active Directory e Windows Live ID (WLID).
Serviços de Fluxo de Trabalho Microsoft® .NET : fornece a infraestrutura necessária para hospedar e gerenciar fluxos de trabalho do WF, com enfoque na orquestração de mensagens por meio do Barramento de Serviços .NET. Vem com novas atividades e ferramentas WF para hospedar e gerenciar instâncias de fluxo de trabalho.
Podemos pensar nesses novos serviços como uma estrutura de serviços .NET centrada na nuvem. Eles estão disponíveis por meio de padrões e protocolos abertos, incluindo REST, SOAP, Atom/AtomPub e WS-*, portanto desenvolvedores de qualquer plataforma podem se integrar a essa estrutura.
Para que essas novas tecnologias parecessem o mais natural possível para os desenvolvedores .NET, a Microsoft também fornece um SDK do .NET Services, que proporciona ao desenvolvedor .NET uma experiência de primeira classe, ocultando várias complexidades que você teria que enfrentar em outras situações.
Usando o SDK do .NET Services, o desenvolvedor pode empregar a experiência que já adquiriu trabalhando com o .NET, especialmente nas áreas de WCF e WF, utilizando as novas extensões de estrutura de trabalho encontradas no SDK (ligações, canais e atividades, por exemplo). O SDK também inclui o suporte da ferramenta Visual Studio para integração ao Portal de Serviços Azure™. Os parceiros da Microsoft oferecem ainda SDKs do Java e do Ruby (veja os links na seção Recursos Adicionais).
Introdução ao Uso do .NET Services
Para começar a usar o .NET Services, navegue para o portal da Plataforma de Serviços Azure™, em http://azure.com, e clique no link “Try It Now” (Testar Agora). Ele o levará para a página “Register for Azure Services” (Registrar-se nos Serviços Azure) mostrada na Figura 3. Essa página contém links importantes para fazer o download dos SDKs, acessar recursos adicionais e navegar para o Microsoft Connect, onde você poderá se registrar para receber um código de convite.
Figura 3: Portal da Plataforma de Serviços Azure™
Em seguida, faça o download do SDK do .NET Services. Note que há alguns SDKs específicos para o desenvolvimento no Windows® Azure™, outro para o desenvolvimento no .NET Services e outros para SQL Data Services e Live Framework. De acordo com o objetivo destes documentos, você só precisa fazer download e instalar o SDK do .NET Services, a fim de replicar os diversos exemplos que vou mostrar.
Após fazer o download do SDK do .NET Services, basta executar o programa de instalação, como mostra a Figura 4, e então você terá os novos assemblies .NET que serão necessários, além de alguns suplementos do Visual Studio que facilitam o aproveitamento dos diversos recursos do .NET Services. Ao iniciar sua experiência no .NET Services, lembre-se de dar uma olhada nos outros recursos disponíveis na página (demonstrações, vídeos, laboratórios práticos etc), projetados para enriquecer seu aprendizado. Você pode fazer o download do SDK sem uma conta, mas para usar os serviços é necessário fazer o registro.
Figura 4: Executando a Instalação do SDK do .NET Services
Para criar uma conta nos Serviços Azure, clique no link “Register for Services” (Registrar-se nos Serviços Azure) mostrado acima. Você terá que fazer logon com um Windows Live ID (WLID), e então será levado ao site do Microsoft Connect, onde preencherá um formulário de registro do Azure Services CTP (versão CTP dos Serviços Azure). Ao concluir o registro no Azure Services CTP, você verá a página mostrada na Figura 5.
Figura 5: Registrando-se na Plataforma de Serviços Azure no site Microsoft Connect
Agora você pode voltar para a página de inscrição do .NET Services (clique no link “.NET Services Portal” mostrado na Figura 5). Você será levado à página ilustrada na Figura 6.
Figura 6: Página de Inscrição do .NET Services
Agora clique em “Sign Up” (Inscrever-se), para poder criar uma solução no .NET Services. Observação: desde o lançamento da versão CTP em março de 2009, não é mais necessário ter o código de convite para criar uma solução no .NET Services.
Criando Sua Primeira Solução
A Figura 7 mostra a página “Create Solution”. Basta inserir um nome de solução exclusivo 2, aceitar os termos de uso e clicar em “Create Solution” (Criar Solução). Assim, sua nova solução do .NET Services será provisionada e associada ao seu WLID. Daí em diante, sempre que entrar no portal da Plataforma de Serviços Azure™, você poderá gerenciar todas as soluções associadas ao seu WLID.
Depois de criar a solução, você verá a página mostrada na Figura 7, que fornece uma senha para a solução. Não se esqueça dela, pois o nome e a senha da solução são as credenciais que você usará para acessar os serviços do .NET Services.
2 O nome da solução deve ser globalmente exclusivo, diferente de todos os que já foram escolhidos pelos outros usuários do .NET Services, e deve ter no mínimo 6 caracteres. Será preciso um pouco de criatividade para encontrar um nome que ainda não tenha sido usado por ninguém.
Figura 7: Concluindo o Processo de Provisionamento da Solução
Após concluir a criação da solução, ela poderá ser gerenciada e usada dentro do portal da Plataforma de Serviços Azure™. Você verá o menu “My Solutions” (Minhas Soluções) do lado direito do portal, depois de fazer o logon com seu WLID (veja a Figura 8). Para gerenciar uma determinada solução, você deve selecioná-la no menu My Solutions, e então será levado à página da Figura 9.
Uma solução é, basicamente, um contêiner de nível superior que serve para gerenciar os diversos ativos do .NET Services.3 Ela serve como contêiner, por exemplo, para seus pontos de extremidade do Barramento de Serviços .NET, seus tipos e instâncias do Serviço de Fluxo de Trabalho .NET e suas regras de transformação de declarações e identidades do Serviço de Controle de Acesso .NET. É extremamente importante gerenciar as credenciais da solução depois de criá-la.
3 É por isso que o nome da solução deve ser exclusivo.
Figura 8: Gerenciando suas Soluções no Menu “My Solutions”
Figura 9: Gerenciando uma Solução Individualmente
Gerenciando as Credenciais da Solução
Ao clicar no link “Solution Credentials” (Credenciais da Solução) da Figura 9, você entra na página “Credential Management” (Gerenciamento de Credenciais), onde pode alterar a senha fornecida durante o processo de provisionamento. Nessa página, também é possível configurar os cartões de informação do Windows CardSpace associados à sua solução, além dos certificados que você quiser associar a ela (veja a Figura 10).
Figura 10: Gerenciando as Credenciais da Solução
No caso do Windows CardSpace e dos certificados, a página pede que você selecione o cartão/certificado que deseja associar, e em seguida faz o upload das informações para a conta de sua solução. Daí em diante, você pode usar, junto com sua conta, as credenciais de cartão e certificado que foram especificadas.
Exemplos no SDK do .NET Services
O SDK do .NET Services traz uma série de exemplos interessantes que mostram como potencializar os diversos recursos oferecidos pelo .NET Services. Depois de instalar o SDK, você encontrará os exemplos neste diretório: C:\Program Files\Microsoft .NET Services SDK (March 2009 CTP)\Samples.
Todos eles foram projetados para solicitar ao usuário que especifique as credenciais da solução dinamicamente. Alguns deles pedirão que você insira o nome e a senha da solução, e outros pedirão que você escolha um cartão de informação do Windows CardSpace. No segundo caso, é necessário selecionar um cartão que tenha sido associado à sua conta anteriormente.
Agora que você sabe como começar a usar o SDK do .NET Services e como provisionar uma conta de solução no .NET Services, estamos prontos para entrar nos detalhes de cada área funcional do .NET Services.
Barramento de Serviços Microsoft® .NET
Uma das necessidades mais comuns das aplicações distribuídas em grande escala é a conectividade. Na verdade, a integração das aplicações é, com frequência, uma das áreas mais caras e problemáticas do TI. Hoje em dia, muitas organizações usam uma solução ESB (Enterprise Service Bus – Barramento de Serviços Corporativo) para superar esses desafios.
O objetivo do Barramento de Serviços .NET, uma das partes básicas do .NET Services, é transformar o padrão ESB em realidade no escopo da Internet, desempenhando um dos papéis da Plataforma de Serviços Azure™. Ele possui muitas das características arquiteturais encontradas nas soluções ESB normais, como o controle de identidade e acesso, a nomenclatura, o registro de serviços e uma malha de mensagens comum. A diferença está no escopo. No caso do Barramento de Serviços .NET, os componentes devem ser projetados para operar na nuvem, em um escopo de Internet global, e de uma forma altamente escalável e federada. É exatamente por isso que antes a Microsoft se referia a esse serviço como Internet Service Bus, ou seja, Barramento de Serviços na Internet (veja a Figura 11).4
Um Barramento de Serviços na Internet possibilitaria a integração de seu produto ESB no local (on-premises) aos seus próprios serviços executados na nuvem, com vários serviços de terceiros fornecidos pela Microsoft ou por outros fabricantes (como aqueles oferecidos dentro da Plataforma de Serviços Azure™), e uma série de aplicações de estação de trabalho, RIA5 e Web, que podem ser executadas em locais satélites, fora do firewall corporativo.
Para isso, a implementação deve fornecer soluções federadas com base em padrões abertos da Internet e em uma malha avançada de sistema de mensagens, capaz de proporcionar uma comunicação bidirecional no escopo da Internet.
Figura 11: Barramento de Serviços na Internet
4 Essa terminologia era usada na documentação do BizTalk Services, mas não é mais empregada oficialmente pela Microsoft. 5 RIA = Rich Internet Application
Lidar com a comunicação bidirecional no escopo da Internet não é tão simples, devido a algumas realidades atuais. Isso se deve principalmente às barreiras introduzidas na rede pelos firewalls e dispositivos NAT, que dificultam a comunicação com os nós que estão atrás dessas camadas. Imagine uma situação em que uma vendedora está viajando e usando sua aplicação por meio de uma rede sem fio, em um hotel de algum lugar do mundo. Como você localizaria e iniciaria a comunicação com o dispositivo dela nesse cenário?
As empresas costumam enfrentar esses desafios abrindo portas de entrada no firewall (para o desespero do administrador de sistema) ou usando soluções temporárias, como DNS dinâmico, mapeamento de portas NAT ou a tecnologia UPnP, que são métodos frágeis, difíceis de gerenciar e suscetíveis a ameaças. Quanto mais as aplicações exigem esse tipo de comunicação bidirecional, maior é a nossa preocupação. É exatamente esse desafio que o Barramento de Serviços .NET nos ajudará a enfrentar.
Conectividade Retransmitida
Apesar desses problemas relacionados à conectividade, algumas das aplicações de Internet mais populares de hoje são inerentemente bidirecionais. Alguns exemplos são as mensagens instantâneas, os jogos online para múltiplos jogadores e, ainda, aplicações de compartilhamento de arquivos ponto a ponto que usam protocolos como o BitTorrent, responsável por grande parte de todo o tráfego atual da Internet. Essas aplicações possuem uma lógica de rede de baixo nível que consegue transpor os firewalls e dispositivos NAT e criar conexões ponto a ponto diretas onde for possível. Geralmente, elas utilizam um serviço de retransmissão central que fornece a lógica transversal de rede (veja a Figura 12).
Figura 12: Usando o Serviço de Retransmissão
A retransmissão permite que o remetente se comunique com o receptor através de um endereço de junção (também chamado de endereço rendevous) compartilhado. O receptor se conecta ao serviço de retransmissão através de uma porta de saída e cria um soquete bidirecional para comunicação,
especificando o endereço de junção em que quer “escutar”. O remetente pode então “enviar” uma mensagem ao serviço de retransmissão usando o mesmo endereço de junção, e esse serviço transmite a mensagem ao receptor registrado no mesmo endereço, por meio do soquete bidirecional já instalado. O remetente não precisa de uma conexão direta com o receptor. E o receptor não precisa ter nenhuma porta de entrada aberta no firewall. Esse tipo de serviço está presente no núcleo do Barramento de Serviços .NET.
Ao usar a retransmissão do Barramento de Serviços .NET, você pode aproveitar as vantagens do sistema de mensagens unidirecional, do sistema de solicitação/resposta, da arquitetura de publicação/assinatura (multicast) e até mesmo do sistema de mensagens assíncrono/desconectado.
No sistema de mensagens unidirecional, um único receptor se registra no serviço de retransmissão para “escutar” mensagens em um determinado endereço de junção dentro do Barramento de Serviços .NET. Então os remetentes podem “enviar” mensagens ao endereço do Barramento de Serviços .NET para que elas sejam “retransmitidas” ao receptor registrado. O uso da comunicação unidirecional por meio da retransmissão constitui um modo de passagem de rede mais agressivo, pois permite que tanto o remetente quanto o receptor usem HTTP (o receptor pode, por exemplo, verificar se há mensagens no serviço de retransmissão via HTTP). O sistema de solicitação/resposta é semelhante, mas geralmente usamos TCP na extremidade do receptor.
O sistema de retransmissão facilita a implementação de arquiteturas de publicação/assinatura, pois permite que múltiplos receptores sejam registrados no mesmo endereço de junção do Barramento de Serviços .NET. Nesse caso, quando o remetente transmite uma mensagem para esse endereço, o serviço de retransmissão distribui a mensagem transmitida a todos os receptores registrados, proporcionando assim recursos de difusão seletiva (multicast).
Tanto os remetentes quanto os receptores podem se comunicar com a retransmissão usando TCP ou HTTP. Normalmente usamos o primeiro quando o desempenho e a taxa de transferência são mais importantes, e o segundo quando estamos mais preocupados com a interoperabilidade ou precisamos garantir a comunicação através dos firewalls.
Conectividade Direta
Além da comunicação retransmitida, o Barramento de Serviços .NET também oferece um recurso que estabelece a conectividade direta entre o remetente e o receptor, a fim de melhorar o desempenho e a taxa de transferência. Os remetentes e receptores continuam se comunicando por meio de um endereço de junção comum, mas nesse caso o serviço de retransmissão tenta ajudá-los a estabelecer uma conexão direta entre si, evitando a necessidade de retransmissão no futuro.
O serviço de retransmissão faz isso por meio de um algoritmo de previsão de porta mútua baseado na investigação de informações do remetente e do receptor. Ele verifica essas informações e faz o melhor possível para prever que portas serão abertas em seus respectivos dispositivos NAT. Então, ele pode fornecer essas informações ao remetente e ao receptor, para que eles tentem estabelecer uma conexão
direta. Se a previsão estiver correta, a conexão terá sucesso, caso contrário, ele pode tentar novamente, até que decida desistir e manter a conexão de retransmissão (veja a Figura 13).
Esse método se assemelha ao que muitas aplicações de mensagem instantânea usam atualmente ao transferir arquivos entre usuários. Quando usar esse recurso, preste atenção na velocidade inicial da transferência de arquivos e verifique se ela aumenta significativamente em algum momento do processo. Se você notar um aumento considerável na velocidade de transferência, saiba que acaba de ocorrer uma atualização para a conexão direta.
Figura 13: Estabelecendo uma Conexão Direta
Endereços de Retransmissão e Controle de Acesso
Uma das coisas mais importantes que devemos aprender, ao usar o Barramento de Serviços .NET, é como estruturar os endereços de junção dos pontos de extremidade. Para expor um ponto de extremidade baseado em TCP, você deve estruturar seus endereços assim:
sb://{solution}.servicebus.windows.net/{user-defined}
Ao expor um endereço baseado em HTTP, basta substituir o esquema de protocolo “sb” por “http”:
http://{solution}.servicebus.windows.net/{user-defined}
Note que é preciso especificar o nome da solução como parte do endereço, para distinguir seus pontos de extremidade daqueles que são usados por outras soluções em todo o Barramento de Serviços .NET. Após o nome da solução, você pode especificar qualquer hierarquia de nomes de URI que quiser usar.
Se estiver dentro do portal da Plataforma de Serviços Azure™, você pode navegar para a página de gerenciamento (veja a Figura 9) de uma de suas soluções e depois para a seção de gerenciamento do
Barramento de Serviços. Essa página fornece uma documentação que mostra como estruturar os endereços de sua solução.
O serviço de retransmissão oferece recursos de controle de acesso por meio de um modelo de segurança baseado em declarações e uma relação de confiança com o Serviço de Controle de Acesso .NET. A retransmissão procura um token de segurança emitido pelo Serviço de Controle de Acesso .NET, a fim de determinar se aquele remetente ou receptor tem permissão para “enviar” ou “escutar” em um determinado endereço de junção do Barramento de Serviços .NET.
Antes que o receptor possa escutar em determinado endereço, ele deve adquirir, no Serviço de Controle de Acesso .NET, um token de segurança que contenha a declaração “#Listen” (Escutar). Ele terá que fornecer credenciais ao Serviço de Controle de Acesso .NET para obter esse token. Os remetentes também precisam adquiri-lo, mas nesse caso o token deve conter a declaração “#Send” (Enviar).
Os remetentes e receptores devem fornecer credenciais ao Serviço de Controle de Acesso .NET para conseguir o token de segurança para a retransmissão do Barramento de Serviços .NET. O Serviço de Controle de Acesso .NET tem suporte para vários tipos de credenciais, como veremos daqui a pouco. Como a retransmissão tem uma relação de confiança com o Serviço de Controle de Acesso .NET, ela é capaz de ler os tokens de segurança emitidos por ele e processar as declarações.
Registro de Serviços
O Barramento de Serviços .NET oferece um registro de serviços para publicar e descobrir referências de pontos de extremidade dentro de uma solução. Ele permite que você publique referências de pontos de extremidade como URIs simples ou como referências oficiais WS-Addressing. Assim, outras pessoas podem descobrir as referências de pontos de extremidade de uma solução navegando para o endereço básico da solução e recuperando um Atom feed que contém as informações.6
Há duas maneiras de publicar referências de pontos de extremidade no registro. O método mais comum consiste em deixar que o WCF cuide disso quando você registrar ouvintes no serviço de retransmissão. Esse serviço preenche automaticamente o registro com referências de ponto de extremidade quando você cria ouvintes por meio das ligações do WCF (e dos canais correspondentes) que vêm no SDK do .NET Services. Você também pode publicar as referências manualmente no registro de serviços, através de uma interface AtomPub.
Filas e Roteadores
o principal objetivo do Barramento de Serviços .NET é atuar como um meio de retransmissão transitório entre duas partes. Essa função básica sempre exige que os ouvintes estejam escutando ativamente no Barramento de Serviços .NET antes que os remetentes comecem a enviar mensagens a eles. Mas e se os remetentes e receptores não executarem sempre ao mesmo tempo? E se não puderem processar as mensagens com a mesma velocidade, devido à largura de banda ou a outras restrições?
6 Isso pode ser feito de forma programática, emitindo uma solicitação HTTP GET para o endereço básico da solução.
Um dos recursos mais requisitados nas versões CTP anteriores era um mecanismo de enfileiramento durável que permitisse a implementação de uma semântica de comunicação assíncrona ou desconectada através da malha de mensagens do Barramento de Serviços .NET.
Para tornar isso possível, a versão CTP de março de 2009 introduziu dois novos elementos primitivos no sistema de mensagens – filas e roteadores – que possibilitam o suporte a uma série de requisitos de comunicação necessários atualmente nas aplicações distribuídas. Esses novos elementos representam uma mudança no modo como a Microsoft planeja o Barramento de Serviços .NET e suas futuras versões. Esses elementos primitivos têm vida longa, ou seja, são duráveis, e não dependem dos ouvintes tradicionais do Barramento de Serviços .NET. Em outras palavras, as filas e os roteadores podem existir mesmo quando não houver nenhum ouvinte ativo.
As filas, como o próprio nome sugere, oferecem uma estrutura de dados durável com a semântica PEPS (primeiro a entrar, primeiro a sair). Você pode criar uma fila dentro do namespace do Barramento de Serviços .NET da mesma forma que cria os ouvintes. Basta escolher um nome para a fila dentro do namespace da solução do Barramento de Serviços .NET, definir uma diretiva de fila e emitir uma solicitação para criar a fila nesse nome.
Quando a fila for criada, os remetentes poderão enviar mensagens para ela e os receptores poderão ler as mensagens da fila, mas a vantagem é que eles não precisam operar ao mesmo tempo. Os remetentes podem enviar as mensagens para as filas usando HTTP(S) ou net.tcp, mas os receptores só podem ler as mensagens das filas usando HTTP(S). Além disso, as filas têm suporte para inspeções com bloqueios, de modo que as mensagens não se perdem quando ocorre uma falha na aplicação. As mensagens podem ter, no máximo, 64 KB e as filas não têm suporte para fluxo contínuo (streaming).
Os roteadores, por outro lado, são responsáveis pelo roteamento de mensagens para um ou mais assinantes. A criação dos roteadores é semelhante à das filas. Basta escolher um nome dentro da solução do Barramento de Serviços .NET, definir uma diretiva de roteador e emitir uma solicitação para criar o roteador nesse nome. Uma das especificações da diretiva de roteador é o modo de distribuição – os roteadores podem distribuir para todos os assinantes (multicast) ou para um único assinante, usando um algoritmo de balanceamento de carga com rodízio (round robin). Depois que os roteadores são criados, um ou mais receptores (incluindo as filas) podem estabelecer assinaturas com o roteador para receber as mensagens.
Depois de criar filas e roteadores em uma solução do Barramento de Serviços .NET, eles começam a aparecer no registro de serviços da solução, contanto que a diretiva de fila e roteador esteja configurada para permitir a descoberta pública. Assim, os consumidores podem encontrar essas construções dinamicamente, durante o tempo de execução.
Um dos fatores mais interessantes das filas e dos roteadores é o modo como se relacionam. As filas, assim como os serviços, podem fazer uma assinatura dos roteadores. Isso proporciona um armazenamento durável para as mensagens roteadas. Quando as mensagens são roteadas para uma fila, podem ficar lá até que uma aplicação consumidora as recupere, o que pode ocorrer muito tempo
depois da saída do remetente. O exemplo da Figura 14 mostra como as filas e os roteadores podem ser compostos para implementar esses diferentes sistemas de mensagens.
Figura 14: Compondo Filas e Roteadores
Nesse exemplo, o roteador front-end tem a diretiva de distribuição ‘All’ (Todos), ou seja, ele fará a difusão das mensagens externas a todos os assinantes. Esse roteador tem dois assinantes: uma fila e outro roteador. A fila funciona simplesmente como um repositório durável para as mensagens externas, até que um serviço (Service A) venha para coletá-las, periodicamente. Note que o roteador secundário está configurado com a diretiva de distribuição ‘One’ (Um), por isso ele fará um balanceamento de carga das mensagens externas para todos os assinantes (Service B, C e D), um por vez. Ele também poderia difundi-las para todos os assinantes se a diretiva de distribuição fosse alterada para ‘All’.
Integração com o WCF
O principal modelo de programação usado para trabalhar com o Barramento de Serviços .NET na plataforma .NET é o WCF. O SDK do .NET Services vem com um conjunto de ligações do WCF novas que automatizam a integração dos clientes e serviços WCF ao serviço de retransmissão. Na maioria dos casos, basta substituir a ligação do WCF que você está usando por uma das ligações do Barramento de Serviços .NET.
A Figura 15 lista todas as ligações do WCF incluídas no Barramento de Serviços .NET e as ligações do WCF padrão às quais elas correspondem. As mais usadas, como a BasicHttpBinding, a WebHttpBinding, a WSHttpBinding e a NetTcpBinding, têm uma ligação correspondente no Barramento de Serviços .NET, com um nome bastante similar (basta inserir “Relay” antes de “Binding”). Existem poucas ligações de retransmissão – NetOneWayRelayBinding e NetEventRelayBinding – que não têm uma ligação correspondente dentro do WCF.
Ligação Padrão do WCF Ligação de Retransmissão Equivalente
BasicHttpBinding BasicHttpRelayBindingWebHttpBinding WebHttpRelayBindingWSHttpBinding WSHttpRelayBindingWS2007HttpBinding WS2007HttpRelayBindingWSHttpContextBinding WSHttpRelayContextBindingWS2007HttpFederationBinding WS2007HttpRelayFederationBindingNetTcpBinding NetTcpRelayBindingNetTcpContextBinding NetTcpRelayContextBindingN/A NetOnewayRelayBindingN/A NetEventRelayBinding
Figura 15: Ligações de Retransmissão do WCF
Para usar o Barramento de Serviços .NET, você deve especificar a ligação de “retransmissão” apropriada (que forneça a semântica de mensagem e conectividade desejada) e um endereço de retransmissão, ao definir o ponto de extremidade do WCF. Então, quando abrir o ServiceHost (para um receptor) ou um ChannelFactory (para um cliente), a infraestrutura WCF cuidará da comunicação com a retransmissão nos bastidores, como descrevemos acima.
Apesar dessa integração ao WCF, vale lembrar que o Barramento de Serviços .NET é baseado em padrões de Internet abertos, o que permite a conexão das aplicações em várias plataformas. Além disso, como ele é construído a partir da Plataforma de Serviços Azure™, suas possibilidades de escalabilidade horizontal são praticamente ilimitadas.
Exemplo Simples Baseado no Barramento de Serviços .NET
Vou mostrar um rápido exemplo de como configurar uma aplicação WCF simples aproveitando os benefícios do Barramento de Serviços .NET. Começaremos com o contrato e a implementação do serviço WCF a seguir:
[ServiceContract]public interface IHelloServiceBus{ [OperationContract] string SayHello(string name);}
class HelloServiceBus : IHelloServiceBus{ public string SayHello(string name) { string greeting = string.Format("Hello {0}!", name); Console.WriteLine("Returning: {0}", greeting); return greeting; }}
Hospedaremos esse serviço na seguinte aplicação de console, que lê no arquivo de configuração da aplicação os detalhes da configuração do serviço:
class Program{ static void Main(string[] args) { Console.WriteLine("**** Receiver ****"); ServiceHost host = new ServiceHost(typeof(HelloServiceBus)); host.Open();
Console.WriteLine("Press [Enter] to exit"); Console.ReadLine();
host.Close(); }}
E começaremos usando a seguinte definição de ponto de extremidade no arquivo de configuração da aplicação. Note que o ponto de extremidade usa NetTcpBinding e o endereço local net.tcp://localhost:8080/helloservicebus:
<configuration> <system.serviceModel> <services> <service name="Microsoft.ServiceBus.Samples.HelloServiceBus"> <endpoint address="net.tcp://localhost:8080/helloservicebus" binding="netTcpBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" /> </service> </services> </system.serviceModel></configuration>
Em seguida, podemos escrever uma aplicação cliente que chame o serviço. O código a seguir mostra como fazer isso usando a mesma definição de contrato, IHelloServiceBus. Supõe-se que os detalhes do ponto de extremidade (de “RelayEndpoint”) serão lidos no arquivo de configuração da aplicação cliente:
class Program{ static void Main(string[] args) { Console.WriteLine("**** Sender ****"); Console.WriteLine("Press <Enter> to start sending messages."); Console.ReadLine();
ChannelFactory<IHelloServiceBus> channelFactory = new ChannelFactory<IHelloServiceBus>("RelayEndpoint"); IHelloServiceBus channel = channelFactory.CreateChannel();
string response = channel.SayHello(".NET Service Bus"); Console.WriteLine(response);
channelFactory.Close(); }}
E finalmente, o arquivo de configuração da aplicação cliente precisa ter uma definição de ponto de extremidade equivalente para se comunicar com o serviço através do ponto de extremidade TCP que ele expõe:
<configuration> <system.serviceModel> <client> <endpoint address="net.tcp://localhost:8080/helloservicebus" binding="netTcpBinding" contract="Microsoft.ServiceBus.Samples.IHelloService" name="RelayEndpoint" /> </client> </system.serviceModel></configuration>
Se você executar as duas aplicações, verá a mensagem “Olá, Barramento de Serviços .NET!” ( Hello .NET Service Bus!) exibida nas duas janelas do console. Nesse caso, há uma conexão TCP direta entre a aplicação cliente e a de serviço.
Agora vamos ver o que é preciso para introduzir o Barramento de Serviços .NET como retransmissão entre a aplicação cliente e a de serviço. Primeiro, temos que reconfigurar o host de serviço para escutar no Barramento de Serviços .NET, e depois reconfigurar o cliente para enviar mensagens através do Barramento de Serviços .NET.
Para reconfigurar o serviço, a fim de escutar no Barramento de Serviços .NET, basta alterar a ligação NetTcpBinding para NetTcpRelayBinding. Também temos que especificar um endereço de junção válido no Barramento de Serviços .NET para o ponto de extremidade. Como minha solução se chama “pluralsight", posso usar o endereço sb://pluralsight.servicebus.windows.net/helloservicebus.
Preciso provar para o serviço de retransmissão que tenho permissão para escutar dentro daquele endereço da solução. Para isso, tenho que apresentar as credenciais da solução ao Serviço de Controle de Acesso .NET para receber um token para o Barramento de Serviços .NET. Há várias formas de fazer isso, mas neste exemplo vou fornecer apenas o nome de usuário e a senha. Você pode especificar as credenciais da solução em código ou configuração – estou usando o segundo método, através do elemento <transportClientEndpointBehavior>. Veja a configuração completa:
<configuration> <system.serviceModel> <services> <service name="Microsoft.ServiceBus.Samples.HelloServiceBus"> <endpoint address= "sb://pluralsight.servicebus.windows.net/helloservicebus" behaviorConfiguration="default" binding="netTcpRelayBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" /> </service> </services> <behaviors> <endpointBehaviors> <behavior name="default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="[solution-name]" password="[solution-password]" /> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> </system.serviceModel></configuration>
Quando abre com essa configuração, o host do serviço WCF envia as credenciais do cliente para o Serviço de Controle de Acesso .NET e adquire um token de segurança para escutar no Barramento de Serviços .NET. Então ele estabelece uma conexão TCP com o serviço de retransmissão e apresenta o token de segurança que adquiriu. Supondo que o serviço tem permissão para escutar naquele endereço (o que significa que o token contém a declaração necessária), o serviço de retransmissão criará um ouvinte para retransmitir as mensagens ao serviço WCF local. A partir daí, se você navegar para o endereço HTTP básico da solução, encontrará esse ponto de extremidade no registro de serviços.
A reconfiguração da aplicação cliente é bastante semelhante. Primeiro temos que alterar o ponto de extremidade para usar a NetTcpRelayBinding e o mesmo endereço de junção em que nosso serviço escutará. Também precisamos configurar o cliente com credenciais. Assim como o serviço, os clientes precisam provar que têm permissão para enviar mensagens a um determinado endereço do Barramento de Serviços .NET, adquirindo um token do Serviço de Controle de Acesso .NET. Veja a configuração completa do cliente:
<configuration> <system.serviceModel> <client> <endpoint address= "sb://pluralsight.servicebus.windows.net/helloservicebus" binding="netTcpRelayBinding" contract="Microsoft.ServiceBus.Samples.IHelloServiceBus" behaviorConfiguration="default" name="RelayEndpoint" /> </client> <behaviors> <endpointBehaviors> <behavior name="default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="[solution-name]" password="[solution-password]" /> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> </system.serviceModel>
Após essas alterações, podemos executar a aplicação host do serviço, seguida pela aplicação cliente, e veremos o mesmo resultado de antes, mas desta vez a comunicação será retransmitida através do Barramento de Serviços .NET (veja a Figura 16), possibilitando a transposição de vários obstáculos de rede encontrados no caminho.
Figura 16: Exemplo HelloServiceBus em Ação
Para saber mais sobre o Barramento de Serviços .NET e ver outros exemplos de código, consulte o Guia do Desenvolvedor do Barramento de Serviços .NET desta série (consulte a seção Recursos Adicionais).
Serviço de Controle de Acesso Microsoft®.NET
A solução de identidade em que a Microsoft vem trabalhando nos últimos anos se baseia na ideia de declarações. O modelo de identidade baseado em declarações permite que os recursos comuns de autenticação e autorização sejam fatorados fora das aplicações e centralizados em serviços externos, que são escritos e mantidos por especialistas em segurança e identidade, beneficiando todos os envolvidos.
Identidade Baseada em Declarações
O Serviço de Controle de Acesso Microsoft® .NET baseado na nuvem faz exatamente isso. Em vez de gravar seu próprio banco de dados para funções e contas de usuários, você pode deixar o Serviço de Controle de Acesso .NET orquestrar a autenticação e a autorização dos usuários. Ele usa armazenamentos de contas de usuário existentes, como o Windows Live ID, o Active Directory e qualquer outro que se baseie nos protocolos de federação padrão. Assim fica mais fácil implementar o logon único nas aplicações. Também é uma ótima forma de centralizar a lógica de controle de acesso e autenticação, o que simplifica suas aplicações.
Quando você constrói uma aplicação com reconhecimento de declarações, o usuário apresenta a identidade a ela como um conjunto de declarações. Uma das declarações pode ser o nome do usuário; outra pode ser seu endereço de email. Essas declarações são fornecidas por uma autoridade de emissão que sabe como autenticar o usuário e onde encontrar seus atributos. A aplicação cliente, que pode ser um navegador ou um cliente rico, trabalha de modo transparente com a autoridade para descobrir essas declarações e transferi-las à sua aplicação (veja a Figura 18).
Figura 17: Usando a Identidade Baseada em Declarações com Serviços Web
O resultado é que sua aplicação recebe todos os detalhes que precisa saber sobre a identidade do usuário em um conjunto de declarações. E as declarações são assinadas, para que você tenha uma garantia criptográfica de sua origem.
Benefícios do Logon Único
No modelo de identidade baseada em declarações, é mais fácil implementar o logon único, e sua aplicação não é mais responsável por nenhum dos itens de segurança a seguir:
Autenticação de usuários Armazenamento de contas e senhas Recorrer a diretórios corporativos para saber detalhes sobre a identidade do usuário Integração a sistemas de identidade de outras plataformas ou empresas
Esse modelo permite que sua aplicação tome decisões relacionadas à identidade, com base nas declarações fornecidas pelo usuário. Essas decisões podem variar de uma simples personalização da aplicação com o primeiro nome do usuário até a autorização de acesso do usuário a recursos mais importantes.
Portal de Administração
O Serviço de Controle de Acesso .NET transforma em realidade a identidade baseada em declarações dentro da Plataforma de Serviços Azure™. Uma grande parte do Serviço de Controle de Acesso .NET é seu sistema de administração.
Figura 18: Portal do ACS
O Serviço de Controle de Acesso .NET possui um portal de administração (veja a Figura 18) dentro do Portal de Serviços Azure™7. Nele são configuradas as regras que determinam como o ACS emitirá declarações para vários usuários e, por fim, responderá a pergunta: “O que você pode fazer?”.
O portal do ACS é uma ótima forma de explorar, aprender e começar a usar o ACS. Em aplicações relativamente simples, ele pode ser a única ferramenta necessária. Mas em sistemas não tão comuns, com centenas ou milhares de usuários e possivelmente um número semelhante de regras, o uso do portal se torna inconveniente, e uma interface programática é mais apropriada. É por isso que o ACS expõe uma interface AtomPub para administração programática. O AtomPub é um protocolo REST que padroniza as operações CRUD (Create, Retrieve, Update, and Delete – Criar, Recuperar, Atualizar e Excluir) básicas para o gerenciamento de recursos remotos. Isso dá origem a um novo padrão de flexibilidade.
Exemplo Simples Baseado no Serviço de Controle de Acesso .NET
A melhor forma de entender o ACS é vê-lo funcionar. Nesta seção, vou mostrar um dos modelos empacotados no SDK do .NET Services, chamado UserNamePasswordCalculatorService.
Este modelo usa o ACS para proteger um serviço WCF simples que oferece quatro operações: Somar, Subtrair, Multiplicar e Dividir. O serviço de calculadora deste exemplo não está interessado no nome, endereço de email ou qualquer outra informação pessoal do usuário. Ele está preocupado apenas em saber se o usuário que fez a solicitação Somar (por exemplo) tem permissão para isso. Vou mostrar como configurar uma solução no ACS para controlar o acesso a essas operações. Para que este modelo funcione, você deve ter uma “solução” no ACS. Explicarei mais adiante o que é uma solução, mas agora basta pensar nela como seu próprio emissor de tokens de segurança na nuvem. Vou usar minha solução pessoal como exemplo; o nome dela é “asolution”.
O serviço de calculadora é uma aplicação que utiliza declarações emitidas pelo ACS para tomar decisões relacionadas à segurança. Este serviço, portanto, como qualquer outra aplicação baseada em declarações, precisa ter seu próprio certificado X.509, que o ACS usa para criptografar os tokens de segurança que o serviço receberá. O modelo vem com um certificado de teste simples chamado localhost.cer, que será usado aqui para começar.
O subdiretório Utils deste exemplo contém o certificado, junto com um arquivo em lotes (installcerts.bat) que o instala no armazenamento pessoal de certificados da máquina local. Eu executei esse arquivo em lotes para instalar o arquivo localhost.pfx na máquina em que o serviço será executado, porque o serviço precisará de acesso à chave privada para descriptografar os tokens produzidos pelo ACS.
7 O Serviço de Controle de Acesso .NET também inclui pontos de extremidade SOAP e REST para administração programática, bem como um conjunto de classes .NET que simplificam a chamada desses pontos de extremidade. Portanto, você pode construir seu próprio console de administração, caso não goste daquele que o ACS fornece ou queira personalizações específicas para cada domínio de problema.
Em seguida, era necessário informar o ACS a respeito da aplicação Calculadora, para que ele saiba o que fazer quando aparecer um cliente pedindo um token de segurança para essa aplicação. As três coisas que o ACS precisa saber sobre a aplicação são:
1. O nome (um URI que os clientes usarão para identificar a aplicação)2. O certificado (o ACS precisa da chave pública para criptografar os tokens emitidos)3. As regras que o ACS deve seguir para emitir declarações
Entrei então em accesscontrol.windows.net e selecionei minha solução (“asolution”). Isso me permitiu adicionar uma aplicação à minha solução, como mostra a Figura 19. Note que, nesse momento, especifiquei o nome da aplicação (“Application URL” – URL da Aplicação) e seu certificado.
Figura 19: Adding an Application to an ACS Solution
Cliquei em Next (Avançar) para ir à página de regras, onde configurei algumas regras bastante simples para a aplicação. O programa cliente que vem com o serviço de Calculadora espera um nome de usuário e uma senha: é assim que ele é autenticado no ACS. Como você verá mais adiante, cada solução do ACS vem com uma senha, portanto você pode usar o nome da solução como nome de usuário e essa senha para autenticá-la no ACS. Quando defini minhas regras, portanto, determinei que o ACS fornecesse permissão para somar, subtrair, multiplicar e dividir apenas se o usuário fornecesse a senha e o nome de usuário da solução corretamente.
A Figura 20 mostra o conjunto de regras resultantes.
Figura 20: Regras da Aplicação Calculadora
Basicamente, o ACS é um mecanismo de transformação de declarações, e você pode ver isso nas regras da Figura 9. Todas as regras que especifiquei procuram uma declaração de entrada: uma declaração “UserName” (nome de usuário) com o valor “asolution” emitida pelo ACS. A única forma de um usuário obter essa declaração do ACS é fornecendo o nome da solução e a senha correspondente ao pedir um token de segurança ao ACS. Com essas quatro regras, qualquer usuário que souber a senha de minha solução receberá quatro declarações "Action" (Ação). A declaração “Action” contém uma cadeia de caracteres que nomeia a ação. Essa cadeia pode ser qualquer coisa: “foo”, “1234” ou “Calculator.Divide”.
Então como essas declarações são usadas no serviço de Calculadora? O serviço simplesmente verifica o token de segurança apresentado pelo cliente e garante que a ação correspondente esteja presente (veja a Figura 21).
public class CalculatorService : ICalculator{ public double Add(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Add"); return n1 + n2; } public double Subtract(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Subtract"); return n1 - n2; } public double Multiply(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Multiply"); return n1 * n2; } public double Divide(double n1, double n2) { AccessControlHelper.DemandActionClaim("Calculator.Divide"); return n1 / n2; }}
Figura 21: Código do Serviço de Calculadora
Eu vou mostrar o código do método auxiliar, DemandActionClaim, mas espero que você entenda, olhando a Figura 21, que estamos apenas procurando uma declaração de ação com um valor específico na cadeia de caracteres, antes de realizar a operação. O método auxiliar vai gerar uma exceção de “acesso negado” se não encontrar a declaração especificada. Por fim, se você provar que sabe a senha da solução, terá permissão para somar, subtrair, multiplicar ou dividir. Se não souber, terá seu acesso negado a todas essas operações.
A Figura 22 mostra o método auxiliar, DemandActionClaim. Talvez você não saiba, mas a construção do WCF levou em conta as declarações. Como o OperationContext dá acesso a um conjunto de declarações? Cada conjunto de declarações representa um token de segurança. Aqui o código executa um loop e encontra o token (há apenas um neste caso, emitido pelo ACS). Então ele procura uma declaração de determinado tipo (o URI embutido em código que termina em /action identifica uma declaração de ação), verifica se ela tem o valor especificado pelo chamador (“Calculator.Add”, por exemplo) e o ACS faz a emissão8. Se esses requisitos não forem cumpridos, o método auxiliar mostrará “Acesso negado”.
public static void DemandActionClaim(string claimValue){ foreach (ClaimSet claimSet in OperationContext.Current .ServiceSecurityContext .AuthorizationContext .ClaimSets) { foreach (Claim claim in claimSet) { if (AccessControlHelper.CheckClaim(claim.ClaimType, claim.Resource.ToString(), "http://docs.oasis-open.org/wsfed/authorization/200706/claims/action", claimValue)) { if (AccessControlHelper.IsIssuedByIbn(claimSet)) { return; } } } } throw new FaultException("Access denied.");}
Figura 22: Código do método auxiliar DemandActionClaim
8 Aparentemente, “Ibn” era um antigo nome de código interno do ACS, portanto não se confunda com o método auxiliar IsIssuedByIbn.
A Figura 23 mostra uma execução do cliente com essas regras definidas. Eu verifiquei se estava digitando corretamente a senha e o nome da solução, para que o acesso fosse permitido. Se digitasse uma senha incorreta, teria recebido uma exceção avisando que eu não podia ser autenticado pelo ACS.
Figura 23: Executando o cliente com as quatro declarações Action (Ação)
Quando a solução estava funcionando, voltei às regras e desativei o Calculator.Divide, desmarcando sua caixa de opção (veja a Figura 20). Então executei o cliente novamente. Desta vez, ele usou apenas três das quatro declarações Action (Ação), e teve o acesso negado para a operação Dividir (Figura 24).
Figura 24: Executando o cliente depois de desativar uma das declarações Action (Ação)
Em seguida, tentei inserir o nome e a senha de outra solução no ACS. A Figura 25 mostra o resultado.
Figura 25: Executando o cliente com outro nome de usuário
Como você pode ver, eu pude especificar o nome de usuário e a senha de outra solução (xyzzy), mas lembre-se que, de acordo com a Figura 20, minhas regras procuram especificamente uma declaração UserName com o valor “asolution”, e não “xyzzy”. Recebi então um token sem nenhuma declaração Action, e não pude acessar nenhuma das operações do serviço de Calculadora (a lógica de autorização DemandActionClaim falhou nesse caso).
Finalmente, tentei inserir “asolution” com uma senha incorreta, para similar um invasor que tenta usar a aplicação sem saber a senha correta. O resultado? O WCF gerou uma exceção indicando que o chamador não podia ser autenticado. Então o ACS nem tentou emitir um token, pois não podia verificar o nome de usuário e a senha que eu forneci.
Se você examinar esse serviço do SDK com mais atenção, verá que ele usa o modelo de programação de declarações embutido no WCF atualmente (System.IdentityModel). Também é possível usar o modelo de programação do Geneva Framework, um método mais recente de programação de aplicações baseadas em declarações, que tende a ser mais flexível e rico em recursos, além de representar com mais precisão o futuro da programação baseada em declarações no Microsoft .NET9.
Para saber mais sobre o Serviço de Controle de Acesso .NET e ver outros exemplos de código, consulte o Guia do Desenvolvedor do Serviço de Controle de Acesso .NET desta série (consulte a seção Recursos Adicionais).
Serviço de Fluxo de Trabalho Microsoft®
Um dos maiores desafios da construção de aplicações distribuídas em grande escala é descobrir como modelar as complexas interações do sistema de mensagens. O Serviço de Fluxo de Trabalho .NET ajuda a projetar a lógica de orquestração de mensagens com o WF, além de fornecer um ambiente hospedado e escalável para executar e gerenciar essas instâncias de fluxo de trabalho WF na nuvem, de forma que você não precise construir seu próprio host do WF.
Host de Fluxo de Trabalho Baseado na Nuvem
O Serviço de Fluxo de Trabalho .NET faz parte da Plataforma de Serviços Azure™ e se integra ao Barramento de Serviços .NET e ao Serviço de Controle de Acesso .NET, proporcionando uma coordenação segura das interações do sistema de mensagens. O Serviço de Fluxo de Trabalho .NET também oferece ferramentas de gerenciamento para criar e gerenciar instâncias e tipos de fluxo de trabalho e uma API de serviço Web. Elas podem ser usadas nas situações em que você talvez queira construir suas próprias ferramentas.
Como o ambiente de hospedagem é construído a partir da Plataforma Windows® Azure™, ele é capaz de escalar sob demanda, e para níveis bastante altos, sem que a organização ou o desenvolvedor tenham que planejar o aumento do hardware ou dos softwares. Já que o tempo de execução do WF está sendo usado, as instâncias de fluxo de trabalho podem ser executadas em um pool de servidores, com a habilidade de mudar de um servidor para outro em cada episódio de execução. O ambiente de hospedagem inclui um serviço de persistência que reproduz e potencializa a segurança do Microsoft SQL Services, para que você possa salvar o estado dos fluxos de trabalho em execução e garantir os recursos de recuperação.
9 A equipe do ACS usou o modelo de programação do WCF na calculadora devido a questões comerciais (eles não tinham permissão para redistribuir o Geneva Framework quando o SDK foi lançado).
Se planeja investir na computação em nuvem, saiba que o Serviço de Fluxo de Trabalho .NET oferece um método simplificado para a coordenação das interações complexas do Barramento de Serviços .NET nas soluções de “nuvem” compostas que você venha a construir.
Hospedagem e Persistência na Nuvem
Construir um host para fluxos de trabalho WF significa tomar decisões sobre os recursos que poderão ser usados no ambiente e a melhor maneira de torná-lo seguro, escalável e estável. O Serviço de Fluxo de Trabalho .NET é baseado no .NET Framework 3.5 e em seus componentes e atividades WF. Contudo, para proporcionar a melhor experiência possível a Microsoft adicionou atividades e serviços personalizados, que geraram algumas restrições com relação aos fluxos de trabalho executados em sua nuvem.
O serviço de persistência usado na nuvem não é o SqlWorkflowPersistenceProvider, utilizado normalmente pelos desenvolvedores que trabalham com WF. Para potencializar o ambiente operacional Azure e proporcionar a melhor experiência em termos de escala e estabilidade na nuvem, o provedor de persistência personalizado usa os recursos de armazenamento do Microsoft SQL Services para manter o estado dos fluxos de trabalho que estão em execução. Afinal, um serviço que possui escala de Internet requer uma tecnologia de armazenamento e recuperação de dados com a mesma escala. No entanto, como o WF é o mesmo mecanismo na nuvem e em suas soluções no local (on-premises), o uso de um provedor de persistência personalizado é transparente para os desenvolvedores de fluxo de trabalho, funcionando como qualquer outro ambiente WF.
Projetando Fluxos de Trabalho para a Nuvem
Para construir fluxos de trabalho para a nuvem, os desenvolvedores usam as mesmas ferramentas familiares do Visual Studio, incluindo o designer que ajuda a criar arquivos de regras e fluxos de trabalho XAML. Esses arquivos XML são então carregados para um servidor da nuvem, onde podem ser usados para criar instâncias de fluxo de trabalho. O SDK do .NET Services inclui um modelo de projeto para a criação de um SequentialCloudWorkflow (fluxos de trabalho sequenciais para nuvem), que é uma versão especializada do modelo padrão SequentialWorkflow (fluxos de trabalho sequenciais). Quando determinamos que os fluxos de trabalho serão executados na nuvem, podemos usar apenas um subconjunto das atividades presentes na biblioteca básica, além do pacote de atividades personalizadas que faz parte do SDK do .NET Services.
A exigência de que os fluxos de trabalho sejam inteiramente declarativos e a restrição do conjunto de atividades ajuda a garantir a estabilidade do ambiente, já que não podemos adicionar a ele um código personalizado. Ao construir um ambiente de hospedagem para fluxos de trabalho escritos por qualquer número de desenvolvedores, em qualquer lugar do mundo, esse nível de controle é fundamental. Como o WF requer confiança total para executar, não existe a possibilidade de colocar o código personalizado em uma área de segurança dos servidores para garantir um conjunto limitado de funcionalidade. Vale lembrar que, embora haja um conjunto limitado de atividades disponíveis no momento, serão
adicionadas outras com o tempo, a fim de aperfeiçoar os recursos dos fluxos de trabalho hospedados na nuvem. Quando forem lançadas as próximas versões do .NET Framework, o Serviço de Fluxo de Trabalho .NET dará suporte a elas também. Além disso, se forem necessários passos personalizados, os recursos de fluxos de trabalho no local (on-premises) poderão ser combinados aos fluxos de trabalho hospedados na nuvem, por meio do Barramento de Serviços .NET.
O SDK do .NET Services vem com um novo modelo de projeto para a construção de fluxos de trabalho na nuvem, um conjunto de atividades novas para a nuvem e uma API cliente para implantar e gerenciar remotamente os fluxos de trabalho hospedados na nuvem.
Atividades na Nuvem
Ao escrever fluxos de trabalho para a nuvem, você deve ter cuidado com as atividades WF que usa (o designer só mostrará o que for permitido). Você pode usar algumas das atividades básicas de fluxo de controle do WF, tais como IfElse, While, Sequence, Suspend, Terminate e FaultHandler. Além destas, você também pode usar a CancellationHandlerActivity e a FaultHandlersActivity nos fluxos de trabalho da nuvem, a fim de possibilitar a manipulação de exceções e a lógica de cancelamento. Normalmente, essas atividades não são adicionadas a um modelo diretamente; o designer de atividades compostas vai adicioná-las automaticamente quando a exibição for ligada na atividade.
Com exceção dessas atividades básicas, você não pode usar as outras atividades do WF ou as atividades personalizadas. Podem ser usadas apenas as novas atividades específicas para a nuvem, que foram incluídas no SDK do .NET Services e estão descritas na Figura 26.
Como o principal objetivo do Serviço de Fluxo de Trabalho .NET é simplificar a orquestração de mensagens, o enfoque dessas atividades é enviar, receber e processar mensagens. Você pode enviar e receber mensagens usando solicitações HTTP tradicionais ou o Barramento de Serviços .NET. Essas atividades aparecerão na caixa de ferramentas do Visual Studio quando você usar o modelo de projeto dos fluxos de trabalho sequenciais para nuvem.
Atividade Função
CloudHttpReceive Receber solicitações HTTP postadas em um determinado URL da instância de fluxo de trabalho
CloudHttpSend Chamar operações GET ou POST HTTP para um determinado URL e obter a resposta
CloudServiceBusSend Enviar uma mensagem a um determinado ponto de extremidade do ServiceBus
CloudServiceBusReceive Receber mensagens de um ponto de extremidade do ServiceBus
CloudXPathRead Ler dados específicos de um XML de entrada
CloudXPathUpdate Definir dados específicos em um documento XML de entrada
CloudDelay Esperar durante um determinado intervalo de tempo
Figura 26: Atividades Específicas para a Nuvem
Exemplo Simples Baseado no Serviço de Fluxo de Trabalho .NET
Vamos ver agora um exemplo simples que ilustra os passos envolvidos na criação e na hospedagem de um fluxo de trabalho na nuvem por meio do Serviço de Fluxo de Trabalho .NET. O fluxo de trabalho será projetado para se comunicar com um serviço WCF executado no local (on-premises) através do Barramento de Serviços .NET.
O primeiro passo é criar um novo projeto de aplicação de console no Visual Studio 2008; ela será o host do serviço no local (on-premises). Adicione a esse projeto uma interface e uma classe para definir um contrato e uma implementação de serviço simples, como mostra a Figura 27. Adicione referências aos assemblies System.ServiceModel.dll e Microsoft.ServiceBus.dll, a fim de obter suporte para o WCF e o Barramento de Serviços .NET.
[ServiceContract(Namespace="")]public interface IHelloService{
[OperationContract(IsOneWay=true)] void SayHello(string input);}public class HelloService : IHelloService{
public void SayHello(string input){
Console.WriteLine(input);}
}
Figura 27: Serviço no Local (On-Premises) Simples
Com o serviço definido, escreva um código no arquivo program.cs para hospedá-lo, usando um ponto de extremidade do Barramento de Serviços .NET. Neste exemplo, como o fluxo de trabalho chamará o serviço, use a NetEventRelayBinding e configure o TransportClientEndpointBehavior para usar credenciais UserNamePassword quando fizer a autenticação no Barramento de Serviços .NET, como mostra a Figura 28.10
10 Lembre-se de usar o nome e a senha de sua própria solução se estiver seguindo esse exemplo.
ServiceHost host = new ServiceHost(typeof(HelloService));
ServiceEndpoint ep = host.AddServiceEndpoint("HelloCloudService.IHelloService",
new NetEventRelayBinding(),"sb://{solution}.servicebus.windows.net/Hello");
TransportClientEndpointBehavior tb = new TransportClientEndpointBehavior();tb.CredentialType = TransportClientCredentialType.UserNamePassword;tb.Credentials.UserName.UserName = "{solution}";tb.Credentials.UserName.Password = "{password}";
ep.Behaviors.Add(tb);
host.Open();Console.WriteLine("Host is listening");Console.ReadLine();host.Close();
Figura 28: Hospedando o Serviço no Local (On-Premises)
O próximo passo é criar o fluxo de trabalho baseado na nuvem no Visual Studio. Para isso, adicione um novo projeto à solução e escolha o projeto CloudSequentialWorkflow11. Usando esse projeto, o tipo de fluxo de trabalho raiz será um tipo de atividade que realiza a validação da estrutura do fluxo de trabalho, para aumentar a probabilidade de sua execução na nuvem. O designer do tipo de fluxo de trabalho raiz também participa da filtragem dos itens disponíveis na caixa de ferramentas.
Depois de criar o projeto e o fluxo de trabalho, as atividades podem ser compostas de várias formas para construir um processo de negócios. O design de um fluxo de trabalho na nuvem não é muito diferente de qualquer outro fluxo de trabalho do WF, a não ser pela restrição de atividades e pela ausência de code-behind.
Nesse exemplo, arraste a atividade CloudXPathUpdate encontrada na guia Cloud Workflow Activities (Atividades de Fluxo de Trabalho na Nuvem) da caixa de ferramentas do Visual Studio, e adicione-a ao fluxo de trabalho. Defina a propriedade InXml como “<SayHello><input> </input></SayHello>” (não use aspas ao inserir esses valores). Note que o elemento “input” está vazio. Para preenchê-lo, defina a propriedade XPathExpression como “/SayHello/input”, para indicar o nó de destino. Finalmente, defina a propriedade InNewValue como “Hello from cloud workflow”. A configuração da atividade deve ser similar à exibida na Figura 29.
11 A versão CTP de novembro de 2008 só tem suporte para o modelo de fluxo de trabalho sequencial. Nas próximas versões, é provável que outros tipos de fluxo de trabalho raiz sejam adicionados à lista de suporte.
Figura 29: Configuração da Atividade CloudXPathUpdate
Em seguida, adicione uma atividade CloudServiceBusSend ao final do fluxo de trabalho. Ela enviará a mensagem criada pela atividade anterior. Primeiro, defina a propriedade Body usando uma ligação de atividade, para que o valor seja lido a partir da propriedade OutXml da atividade CloudXPathUpdate configurada anteriormente. Configure a atividade definindo a propriedade Action como “urn:IHelloService/SayHello” e a ConnectionMode como “MultiCast”. Finalmente, defina a propriedade URL com o endereço correto em que seu serviço está escutando dentro do Barramento de Serviços .NET: “sb://{solution}.servicebus.windows.net/Hello”.
Agora a atividade tem todos os dados que necessita para construir corretamente uma mensagem e enviá-la ao ponto de extremidade do Barramento de Serviços .NET. Quando você terminar, o fluxo de trabalho concluído ficará como o da Figura 30.
Figura 30: Fluxo de Trabalho Concluído
Esse exemplo é simples – praticamos apenas duas das atividades disponíveis para uso na nuvem. Os desenvolvedores podem usar várias atividades compostas para criar passos de cancelamento e lógica de manipulação de falhas, assim como fazem no WF. Note que a ligação de atividades, ou de propriedades de uma atividade às de outra, não só é possível como necessário, já que não há um arquivo code-behind para ser usado. Os fluxos de trabalho devem ser verdadeiramente declarativos, e a ligação de atividades é a forma de passar os dados em um modelo de fluxo de trabalho declarativo.
Para testar a solução, certifique-se de que a aplicação de console que está hospedando o serviço é o projeto de inicialização e pressione CTRL+F5 (ou selecione Debug | Start Without Debugging – Depurar | Começar Sem Depurar). Quando o serviço tiver registrado o ponto de extremidade, clique com o botão direito no fluxo de trabalho na nuvem do Visual Studio, na superfície de design, e selecione o item de menu “Deploy Workflow” (Implantar Fluxo de Trabalho). Será aberta uma caixa de diálogo de publicação, solicitando informações e credenciais da solução, como mostra a Figura 31.
Figura 31: Caixa de Diálogo para Implantação do Fluxo de Trabalho na Nuvem do Visual Studio
Insira o nome e a senha de sua solução e clique no botão Deploy & Run (Implantar e Executar). Depois que a solução for implantada e iniciada corretamente, sua mensagem aparecerá na aplicação de console que está hospedando o serviço conectado ao Barramento de Serviços .NET. Parabéns por executar com sucesso o seu primeiro fluxo de trabalho na nuvem!
Além da integração ao Visual Studio, o Serviço de Fluxo de Trabalho .NET oferece uma interface de serviço Web para o gerenciamento de tarefas, incluindo a implantação de tipos de fluxo de trabalho e o gerenciamento de instâncias. O SDK vem com uma biblioteca de cliente para se integrar à interface de gerenciamento através do código .NET tradicional. O portal do .NET Services pode ser usado em qualquer navegador Web para definir e editar tipos de fluxo de trabalho, bem como gerenciar instâncias de fluxo de trabalho. A combinação do portal, das ferramentas do Visual Studio e da API cliente proporciona ao desenvolvedor uma boa experiência, que pode ser estendida e aperfeiçoada com o tempo.
Para saber mais sobre o Serviço de Fluxo de Trabalho .NET e ver outros exemplos de código, consulte o Guia do Desenvolvedor do Serviço de Fluxo de Trabalho .NET desta série (consulte a seção Recursos Adicionais).
Juntando Tudo
O .NET Services oferece os serviços de bloco de construção que você necessita para construir aplicações baseadas na nuvem ou com reconhecimento de nuvem na Plataforma de Serviços Azure™. Com o
Barramento de Serviços .NET, você pode conectar suas aplicações no local (on-premises) existentes aos novos investimentos que está fazendo na nuvem. Esses ativos da nuvem poderão se comunicar com seus serviços no local (on-premises) através dos recursos de passagem de rede fornecidos pela retransmissão do Barramento de Serviços .NET. Além de vencer os obstáculos de rede (firewalls, NATs etc) encontrados no escopo da Internet, a valiosa malha de conectividade oferecida pelo Barramento de Serviços .NET acomoda uma série de padrões de sistema de mensagens, incluindo o sistema unidirecional, o de solicitação/resposta, o de publicação/assinatura (multicast), o assíncrono (filas) e outros.
O Barramento de Serviços .NET depende do Serviço de Controle de Acesso .NET para proteger o acesso à retransmissão. Com o Serviço de Controle de Acesso .NET, é possível potencializar o modelo moderno de identidade baseada em declarações, sem que tenhamos que construir uma infraestrutura complexa de segurança. O Barramento de Serviços .NET confia nas declarações produzidas pelo Serviço de Controle de Acesso .NET, portanto pode processá-las e, assim, determinar se o remetente ou receptor tem permissão para enviar ou ouvir em um determinado endereço do Barramento de Serviços .NET. Os remetentes e receptores têm que apresentar credenciais ao Serviço de Controle de Acesso .NET para adquirir um token de segurança para o Barramento de Serviços .NET. Eles podem fornecer as credenciais da solução, identidades do Active Directory ou WLIDs para que o Serviço de Controle de Acesso .NET faça a autenticação (tudo isso pode ser configurado no portal). Em seguida, o Serviço de Controle de Acesso .NET emite o token de segurança para a retransmissão do Barramento de Serviços .NET. Esse é apenas um exemplo de uso do Serviço de Controle de Acesso .NET.
Ele também pode ser usado em conjunto com seus próprios serviços. O modelo a ser seguido seria bastante similar ao que acabo de descrever. Primeiro, estabeleça uma relação de confiança entre seu serviço e o Serviço de Controle de Acesso .NET (fornecendo um certificado). Depois, configure o Serviço de Controle de Acesso .NET com os tipos de credencial em que ele deve confiar, além de algumas regras declarativas para produzir as declarações de saída que sua aplicação necessita. Como essas declarações serão criptografadas com seu certificado, apenas o seu serviço poderá processar o token de segurança resultante. Você pode então escrever o código dentro de seu serviço para processar as declarações fornecidas pelo Serviço de Controle de Acesso .NET (como ocorre na retransmissão do Barramento de Serviços .NET). Esse modelo de identidade baseada em declarações é bastante flexível. Ele possibilita a centralização da autenticação e da lógica de transformação de declarações, além de federar identidades de uma série de fontes diferentes (WLID, Active Directory, parceiros corporativos etc).
Finalmente, o Serviço de Fluxo de Trabalho .NET permite uma coordenação segura das interações do sistema de mensagens no escopo da Internet, com a ajuda do Barramento de Serviços .NET e do Serviço de Controle de Acesso .NET. Você pode projetar fluxos de trabalho orientados a mensagens usando o designer do Visual Studio. O SDK traz um novo conjunto de atividades baseadas na nuvem, que você pode utilizar para construir definições de fluxo de trabalho baseadas na nuvem. Para que haja hospedagem e execução, faça o upload da definição de fluxo de trabalho em XAML (usando um suplemento do Visual Studio) para a Plataforma de Serviços Azure™. Durante a execução das instâncias de fluxo de trabalho, elas podem se comunicar diretamente com outros serviços encontrados na Internet e com os serviços de suas redes privadas, através da malha do Barramento de Serviços .NET.
A experiência de design gráfico de fluxos de trabalho oferecida pelo WF simplifica a proposta de construção de serviços compostos baseados na nuvem. O Serviço de Fluxo de Trabalho .NET é integrado ao Barramento de Serviços .NET e ao Serviço de Controle de Acesso .NET, portanto eles podem se juntar na criação de processos corporativos.
Em geral, a família .NET Services fornece ao desenvolvedor os blocos de construção básicos para aplicações na nuvem, tendo em mente a Plataforma de Serviços Azure™. Há uma enorme sinergia e integração entre eles, e é provável que você tenha contato com todos quando construir uma aplicação completa baseada na nuvem.
Sumário
A Plataforma de Serviços Azure™ representa uma estratégia abrangente da Microsoft para facilitar a conscientização dos desenvolvedores a respeito das oportunidades inerentes à computação em nuvem. O Microsoft® .NET Services, uma das principais partes dessa plataforma, foi projetado especificamente para ajudar os desenvolvedores .NET a fazer essa mudança. O .NET Services fornece infraestrutura e blocos de construção centrados na nuvem para as áreas de conectividade de aplicações, controle de acesso e hospedagem e gerenciamento de fluxos de trabalho. Esses blocos de construção serão fundamentais para a experiência dos desenvolvedores .NET na nuvem nos próximos anos. Para mais informações sobre o Barramento de Serviços .NET, o Serviço de Controle de Acesso .NET e o Serviço de Fluxo de Trabalho .NET, leia o artigo detalhado de cada tópico que faz parte desta série de documentos do .NET Services.
Recursos Adicionais
Abaixo são fornecidos links para vários recursos que vão aumentar seu conhecimento a respeito do pacote Microsoft® .NET Services e dos serviços descritos neste documento.
Série de Whitepapers do Microsoft® .NET Services
Introdução ao Microsoft .NET Services para Desenvolvedores (este documento)o http://go.microsoft.com/?linkid=9638347
Guia do Desenvolvedor do Barramento de Serviços Microsoft® .NET o http://go.microsoft.com/?linkid=9638348
Guia do Desenvolvedor do Serviço de Controle de Acesso Microsoft® .NETo http://go.microsoft.com/?linkid=9638349
Guia do Desenvolvedor do Serviço de Fluxo de Trabalho Microsoft .NETo http://go.microsoft.com/?linkid=9638350
Recursos do Microsoft® .NET Services
Plataforma de Serviços Azureo http://www.microsoft.com/azure/services.mspx
Microsoft® .NET Serviceso http://www.microsoft.com/azure/netservices.mspx
Java SDK para Microsoft .NET Serviceso http://www.jdotnetservices.com/
Ruby SDK para .NET Serviceso http://www.dotnetservicesruby.com/
Sobre o Autor
Aaron Skonnard é um dos fundadores da Pluralsight, um provedor de treinamento especializado no Microsoft .NET que oferece tanto cursos online quanto ministrados por instrutores. Aaron é autor de inúmeros livros, artigos e whitepapers, além de cursos da Pluralsight sobre Serviços Azure, REST, WCF e BizTalk. Aaron passou anos desenvolvendo cursos, dando palestras e ensinando desenvolvedores de todo o mundo. Você pode entrar em contato com ele acessando http://pluralsight.com/aaron ou http://twitter.com/skonnard.
Agradecimentos
Obrigado a Keith Brown e Matt Milner, coautores desta série de whitepapers do .NET Services. Eles são responsáveis, sobretudo, pelo conteúdo relacionado a controle de acesso e fluxo de trabalho encontrado neste documento.
Obrigado a John Shewchuk e Dennis Pilarinos pela visão pioneira que levou ao Microsoft® .NET Services, o que ajudou a remodelar o futuro do desenvolvimento .NET na nuvem. Agradeço também a Anjan Das, David Wortendyke e Scot Gellock pelos comentários específicos durante a elaboração deste documento.