Este artigo foi traduzido por máquina.

Computação de nuvem

Criação de aplicativos com serviços .NET distribuídos

Aaron Skonnard

Este artigo se baseia em uma versão de pré-lançamento do .NET Services. Todas as informações estão sujeitas a alterações.

Conteúdo

Serviços do .NET
O que há em serviços .NET?
Criando uma solução de serviços .NET
Instalando os serviços do .NET SDK
O serviço de controle de acesso .NET
Configurando um serviço
O barramento de serviço do .NET
Comunicação por meio do barramento de serviço do .NET
O serviço de fluxo de trabalho a .NET
Criando um fluxo de trabalho de nuvem

em conferências de desenvolvedores a Professional 2008 (PDC) em Los Angeles, a Microsoft anunciou uma nuvem de novo inovadora computação estratégia que será Desdobrar nos próximos anos alguns. A plataforma de nuvem Microsoft — oficialmente conhecido como a plataforma de serviços Azure — torna mais fácil para os desenvolvedores do .NET mover seus aplicativos (ou partes dele) para a nuvem usando o mesmo ferramentas e APIs já estiver familiarizados com.

Windows Azure apresenta a base da plataforma Microsoft nuvem. Pense Azure do Windows como um sistema operacional de nuvem baseados no Windows. Ele fornece um ambiente de execução altamente escalonável para execução de aplicativos .NET e armazenar dados no Microsoft data centers em todo o mundo. Criação de aplicativos no Windows Azure pode proteger você de muitos dos aspectos de infra-estrutura caro e importunos de seu aplicativo, permitindo que você se concentrar em vez disso, no desenvolvimento e sua empresa.

A Microsoft fornece várias ofertas de serviço criadas sobre a base do Windows Azure, incluindo .NET Services, SQL Services, serviços Live, SharePoint Services e muito mais. Combinar essas ofertas de serviço com a base do Windows Azure formulários a plataforma de serviços Azure completa (veja a Figura 1 ). Cada um dessas ofertas de serviço inclui vários serviços individuais que você pode escolher para chamar em seus aplicativos. Microsoft ativamente está criando na plataforma de serviços de Azure em vários aplicativos de consumidor conectadas à como o Windows Live, Microsoft Office Live, on-line do Microsoft Exchange, Microsoft SharePoint online, bem como outras pessoas. Você terá a oportunidade para fazer o mesmo, aproveitando quaisquer serviços Azure fornecem valor para você.

Figura 1 A plataforma de serviços Azure

Em todo este artigo, vou para mergulhar na oferta de serviços do .NET na plataforma de serviços Azure, com base na versão CTP 2008 novembro/dezembro. Como você pode ver da Figura 1 , isso é apenas uma parte pequena da estratégia de plataforma de nuvem mais ampla, mas é um interesse específico para desenvolvedores .NET mover em direção a nuvem.

Serviços do .NET

Se você considerar mesmo um Microsoft conectado desenvolvedor de sistemas usando tecnologias como o WCF (Windows Communication Foundation), Windows Workflow Foundation (WF) e o BizTalk Server, você será deseja preste especial atenção aos serviços do .NET. Isso é onde a maioria das tecnologias que você se preocupa com aparecerá dentro a plataforma de serviços Azure. (Ele é interessante observar que o nome original para o projeto incubação era "serviços do BizTalk". O nome oficial — serviços .NET — foi anunciado no PDC junto com o Windows Azure.)

Se desejar pensar Windows Azure como "o Windows na nuvem", você pode pensar serviços .NET como "o Microsoft .NET Framework na nuvem." Hoje, os desenvolvedores .NET dependem muito do .NET Framework para criação de aplicativos direcionar a plataforma Windows. O .NET Framework fornece blocos de construção comuns exigidos por muitos aplicativos, tornando mais fácil de obtê-los up e em execução rapidamente. Serviços .NET desempenha uma função semelhante a plataforma de serviços Azure fornecendo alguns blocos de construção comuns que tornam mais fácil escrever aplicativos com base em nuvem.

Apesar das semelhanças, também há uma diferença elegante entre o .NET Framework e serviços .NET. Embora o .NET Framework fornece os blocos de construção na forma de assemblies do .NET, serviços .NET fornece os blocos de construção na forma de serviços hospedados em execução em centros de dados do Microsoft. Ao usar serviços .NET, há um limite claro entre a lógica por premissa e os serviços do .NET em execução na nuvem. É seu trabalho para escrever esses serviços para suas soluções de negócios. Microsoft irão hospedar, gerenciar e manter os serviços hospedados que dependem de seus aplicativos.

Fornece a você programar em serviços .NET, integrando com os serviços individuais. Embora seja chamado ".NET" Services, você realmente não precisa usar .NET para fazer isso; você pode integrar com o .NET Services através do SOAP padrão e REST interfaces que ele expõe. Microsoft fornece um SDK de serviços .NET que otimiza a experiência do desenvolvedor .NET e há até mesmo Java e Ruby SDKs disponíveis da comunidade.

O que há em serviços .NET?

Se você considerar que seria necessário para mover o aplicativo para uma plataforma de nuvem, existem alguns requisitos comuns que você vai mais provavelmente deparar. Em primeiro lugar, será necessário uma maneira de descrever e compactar seus processos de negócios, ou fluxos de trabalho, para que possam ser executadas e gerenciados na nuvem. Em segundo lugar, será necessário uma maneira de se comunicar entre seus fluxos de trabalho cloud-com base e seus aplicativos em premissa, atravessando qualquer firewalls ou dispositivos de conversão (NAT) de endereço de rede que podem ser na forma. E em terceiro lugar, você terá uma maneira de proteger o comunicação e controle de acesso aos seus recursos cloud-com base em vários.

A maioria dos aplicativos de nuvem precisam lidar com pelo menos um desses requisitos. Se você tivesse que criar esse tipo de infra-estrutura de si mesmo, ele pode alterar drasticamente a proposta de valor total. Essas são exatamente as áreas de serviços do .NET na versão CTP novembro/dezembro 2008.

Especificamente, serviços .NET atende a essas necessidades de infra-estrutura de nuvem por meio de três serviços individuais bloco de construção: o serviço de fluxo de trabalho .NET, o barramento de serviço do .NET e o serviço de controle de acesso .NET (consulte a A Figura 2 Para obter detalhes).

O barramento de serviço .NET depende do serviço de controle de acesso .NET para controlar o acesso ao serviço de retransmissão por remetentes e ouvintes. Isso significa que todos os remetentes e ouvintes preciso obter um token do serviço de controle de acesso .NET para poderem usar o barramento de serviço do .NET. O serviço de fluxo de trabalho a .NET integra o barramento de serviço .NET para viabilizar transmitir mensagens através do serviço de retransmissão, permitindo uma variedade de interessante cenários de comunicação em seus fluxos de trabalho cloud-com base. Juntos, esses serviços oferecem uma malha de desenvolvimento atraente para a criação de aplicativos na nuvem.

Criando uma solução de serviços .NET

Antes de começar com o .NET Services, você precisará visite oAzure plataforma de serviços de portale criar uma solução. Este artigo se baseia na versão CTP de novembro/dezembro de 2008, para que será necessário um token de convite antes de poder criar uma solução de serviços .NET. Você pode obter um token de convite, seguindo o "Experimente agora" links em portal.Windows a plataforma de serviços Azure Azure e serviços .NET exigir tokens de convite diferentes, caso Certifique-se de que você solicitação um serviços .NET token, muito. Depois de aprovados, você receberá o token de serviços .NET convite por email.

Uma vez recebido um código de convite, você pode navegar para a área de serviços .NET dentro do portal e criar uma nova solução. Você terá que inserir um código de convite válido e especifique um nome de solução, ele será fornecer uma nova solução de serviços do .NET e fornecer uma senha de solução. (O nome da solução serve como o nome de usuário para fins de autenticação).

Durante o processo de configuração, você poderá ser solicitado a entrar usando um Windows Live ID (WLID), portanto, a nova solução pode ser associada à sua conta. Várias soluções podem ser associadas com um único WLID, mas cada solução requer um código exclusivo convite hoje. Sempre que você faça logon para o portal com sua WLID, você verá todas as suas soluções listadas em "Meu soluções" no lado direito da página. Quando você seleciona uma solução específica, ela levará você a uma página para gerenciar diferentes aspectos dos serviços do .NET em que solução específica (veja a Figura 3 ).

A Figura 3 Gerenciando uma solução

Uma solução é basicamente um recipiente de nível superior para gerenciar os vários ativos de serviços .NET. Por exemplo, ele é um recipiente de seus pontos de extremidade .NET Service Bus, seus tipos de serviço de fluxo de trabalho do .NET e instâncias e suas identidades do serviço de controle de acesso .NET e afirma regras de transformação.

Instalando os serviços do .NET SDK

Você também precisará baixar e instalar o SDK de serviços .NET, que você também pode obter do portal Azure dos serviços de plataforma. Quando você instala o SDK, ele irá adicionar vários assemblies do .NET para seu computador e algumas Visual Studio suplementos que facilitam integrar serviços .NET através de programação.

Você encontrará os novos assemblies no diretório de instalação, que está localizado por padrão em \Arquivos de Programas\Microsoft .NET Services SDK. Os módulos principais incluem Microsoft.ServiceBus.dll, Microsoft.Workflow.Activities.dll e Microsoft.AccessControl.Management.dll. O diretório de instalação também contém exemplos que ilustram como usar cada serviço e os principais recursos fornecidos pelo cada serviço. Certifique-se de check-out os vários exemplos quando começar sua viagem.

Se você iniciar o Visual Studio, você também observará um novo modelo de projeto chamado CloudSequentialWorkflow (sob o tipo de projeto CloudWorkflow). Use este modelo de projeto para criar fluxos de trabalho do WF que você deseja hospedar no serviço de fluxo de trabalho de .NET. O SDK também instala um suplemento do Visual Studio que facilita implantar seus fluxos de trabalho para o serviço de fluxo de trabalho a .NET.

É interessante observar que a implementação de serviços do .NET na verdade, deriva fromWCF e o WF no .NET Framework 3.5. O SDK do Services .NET é capaz de criar em que sinergia para tornar o desenvolvedor de consumidor experiência tão direto quanto possível para aqueles já familiarizado com os modelos de programação WCF e o WF. Se você estiver no que camp, a mecânica de programação .NET Services será sentir muito natural para você. No final, é principalmente uma questão de aprender algumas novas ligações de WCF (para o barramento de serviço .NET), configurar essas ligações e Noções básicas sobre algumas novas atividades (para o serviço de fluxo de trabalho do .NET).

As seções restantes, VOU dar uma olhada rápida em cada serviço e percorrer um exemplo do uso de cada um deles. No final, você deve sentir confortável como começar por conta própria.

O serviço de controle de acesso .NET

Vamos começar examinando o serviço de controle de acesso .NET. Últimos vários anos, a Microsoft foi movimento em direção um modelo de identidade baseada em declarações que permite que você fator decisões de autenticação e autorização check-out de seus aplicativos e em um serviço externo que pode ser mantido centralmente por especialistas em segurança. Com esse modelo, as especialistas em segurança controlar o processo de autenticação de usuários e emitir declarações sobre os usuários. Seus aplicativos podem simplesmente confiar as declarações apresentadas pelo serviço e tome decisões com base nessas declarações (evitando autenticação).

Ao usar um modelo de identidade baseada em declarações, o usuário apresentará sua identidade para seu aplicativo como um conjunto de declarações. As declarações são simplesmente declarações sobre o usuário — eles podem ser algo como um nome, um endereço de email ou uma classificação de comentários. As declarações são fornecidas por um provedor de identidade que sabe como autenticar o usuário e suas atributos (talvez de um diretório da empresa). O aplicativo cliente transparente funciona com a autoridade de emissão para obter essas declarações e apresentá-los para o aplicativo.

O serviço de controle de acesso do Microsoft .NET é um serviço cloud-com base em centralizado que torna fácil perceber dentro a plataforma de serviços Azure esse modelo. Hoje, o serviço de controle de acesso .NET pode funcionar como um provedor de identidade (, autenticação de usuários por meio das credenciais de solução atribuídas durante o processo de provisionamento), mas que não é realmente o que ele é destinado a fazer. Ele foi projetado para dependem principalmente provedores de identidade existentes, como WLID e o serviço de token de segurança de servidor "Genebra" ou qualquer provedor de identidade que ofereça suporte os protocolos de padrão de federação. Isso torna o single sign-on um resultado natural.

A principal responsabilidade dos serviços de controle de acesso .NET é fornecer um conjunto de declarações que são úteis para o seu aplicativo. Isso normalmente significa converter as declarações de entrada (que vêm de um provedor de identidade como WLID ou o servidor "Genebra") em um conjunto de declarações de saída que têm significado para o seu aplicativo. Você pode pensá-lo como um mecanismo de transformação de declarações configurável na nuvem.

Configurando um serviço

Você configurar o serviço de controle de acesso .NET através do portal de administração fornecido em uma solução específica (veja a Figura 4 ). Isso é onde você configure as regras que determinam como emitirá declarações para os usuários que ele saiba sobre ou como resultado da transformação de declarações de outros provedores.

A Figura 4 O portal de administração .NET acesso controle Service

Em vez de configurar um serviço de exemplo do meu próprio, vou mostrar o modo como o serviço de controle de acesso .NET é configurado para o barramento de serviço do .NET. Se você clicar no botão Avançado dentro do portal de administração, você verá uma lista suspensa de nomes de solução que representam os proprietários dos vários escopos. Um escopo é uma coleção de regras de transformação de declaração. Quando eu seleciono a solução de barramento de serviço da minha conta, ela mostra um escopo de

http://servicebus.Windows. NET/serviços/Pluralsight /

Ao usar o barramento de serviço .NET, você irá configurar pontos de extremidade que use esse escopo de barramento de serviço como o URI de base (seu será ser personalizado para sua conta, é claro). Cada solução vem pré-configurada com um conjunto de regras de controle de acesso para tanto o barramento de serviço do .NET e o serviço de fluxo de trabalho do .NET.

Se você clicar em gerenciar, você pode inspecionar a lista de regras configurado para um determinado escopo (veja a Figura 5 ). Este exemplo específico, existem duas regras que procuram uma declaração de nome de usuário de entrada que contém um valor da pluralsight. Um produz uma declaração de saída de envio e o outro produz uma declaração de saída de escuta. O barramento de serviço .NET foi desenvolvido para procurar por essas declarações controlar o acesso ao seu namespace de ponto de extremidade. Qualquer usuário que apresenta uma declaração de envio será permitido para enviar mensagens para o escopo do URI, e qualquer usuário que apresenta uma declaração de escuta terão permissão para criar uma escuta no escopo de URI. Se eu fosse excluir a regra que gera o símbolo de envio, minha conta pluralsight não poderá enviar mensagens através do barramento de serviço do .NET dentro desse escopo — ele só poderá ouvir.

A Figura 5 Confi guring regras para um escopo

É fácil adicionar suporte semelhante a seus próprios serviços. Você simplesmente definir novo escopo URIs dentro do portal de administração e a necessidade de definir regras para produzir as declarações esperado pelo seu service.Within lógica de seu serviço, será necessário escrever um código para inspecionar as declarações de entrada e para tomar decisões de autorização com base no que declarações estão presentes e o que eles contêm. O WCF e a nova estrutura de "Genebra" tornam isso possível por meio de seus modelos de programação baseada em declarações. Para obter um exemplo completo, consulte o exemplo .NET Access Control Service Introdução no SDK.

O barramento de serviço do .NET

O principal foco o barramento de serviço do .NET é fornecer conectividade bidirecional no escopo de Internet, que pode ser desafiadora devido aos nunca-para-comum firewalls e dispositivos NAT que restringem o tráfego de entrada na maioria dos ambientes. O barramento de serviço .NET faz isso fornecendo um serviço centralizado de retransmissão a nuvem que fornece a lógica de passagem de rede necessário (consulte a Figura 6 ).

A Figura 6 retransmissão de barramento do .NET Service

A retransmissão torna possível para um remetente para se comunicar com um receptor por meio de um endereço rendezvous. O destinatário se conecta à retransmissão através de uma porta de saída e cria um soquete bidirecional para especificar o endereço rendezvous quer escutar de comunicação. O remetente, em seguida, pode transmitir mensagens para a retransmissão especificando o mesmo endereço rendezvous como o destinatário. Quando a retransmissão recebe uma mensagem, ele retransmite a mensagem para a escuta correspondente (ou ouvintes, no caso de multicast) que compartilham o mesmo endereço rendezvous. A retransmissão transmite mensagens para o receptor através o soquete bidirecional já no lugar, o que significa que nenhuma porta de entrada é exigida pelo destinatário. Isso explica por que o mecanismo funciona através de firewalls e dispositivos NAT (como um aplicativo de bate-papo típica).

O oferece suporte de barramento de serviço do .NET estilos de uma variedade de mensagens incluindo unidirecional, a solicitação-resposta e até mesmo publique-inscrever-se. Ele oferece suporte a HTTP e TCP para comunicações, dependendo se você se preocupa interoperabilidade ou desempenho. A retransmissão mesmo fornece um modo para negociar uma conexão de TCP direta entre dois nós de mesmo nível com base em um algoritmo de previsão de porta. Ignorando a retransmissão permite maior taxa de transferência ao transmitir as mensagens grandes. Em geral, o barramento de serviço .NET fornece uma boa dose de flexibilidade na adaptação a uma variedade de cenários de comunicação mais comuns hoje.

É importante compreender como estruturar os URIs para o barramento de serviço do .NET pontos de extremidade. Ao expor um ponto de extremidade baseados em TCP, será necessário estruturar os endereços da seguinte maneira:

sb://servicebus.windows.net/services/{solution}/{name}/{name}/...

Ao expor um endereço HTTP com base, simplesmente substitua o esquema de protocolo sb http.Observe que você especifica o nome da solução como parte do endereço para distinguir os pontos de extremidade de os usados por outras soluções em todo o barramento de serviço do .NET.Este é o mesmo endereço que foi usado como o escopo URI a configuração do serviço de controle de acesso .NET.Após o nome de solução, você tem total controle para especificar qualquer hierarquia de nome URI você gostaria de usar para os pontos de extremidade.

Remetentes e destinatários precisará apresentar a declaração de envio ou de escuta para o barramento de serviço .NET (adquiridas do serviço de controle de acesso .NET) em ordem para enviar ou escutar um endereço específico.Como o barramento de serviço .NET tem uma relação de confiança com o serviço de controle de acesso .NET, ele é capaz de ler os tokens de segurança que emite e processar essas declarações.Sem essas declarações, você não pode usar a retransmissão (a menos que uma determinada empresa tiver sido configurada para permitir o envio anônimo, que é possível).

A maneira mais fácil para integrar a retransmissão de barramento de serviço do .NET é através das ligações de retransmissão novas do WCF que acompanham o SDK.Há uma vinculação de retransmissão equivalente para a maioria das ligações HTTP/TCP do WCF interna (veja a Figura 7 ).Há também alguns novos que não têm uma contraparte não criptografada, como NetOneWayRelayBinding (para percursos unidirecionais agressivos) e NetEventRelayBinding (para cenários multicast unidirecionais, normalmente usado para publicação/assinatura).Quando você usa as ligações de retransmissão em vez das ligações padrão, os componentes de canal WCF subjacentes cuidam de se comunicar com o serviço de controle de acesso .NET e a retransmissão por trás dos bastidores, e seu código talvez não ainda precise alterar.

O barramento de serviço .NET também fornece um registro de serviço na forma de um Atom feed.Este feed está disponível no endereço base da solução por meio de padrão de solicitações HTTP GET.O feed conterá automaticamente informações sobre pontos de extremidade escuta ativo dentro de uma solução específica.

Comunicação por meio do barramento de serviço do .NET

Agora vamos examinar um exemplo completo de se comunicar através do barramento de serviço do .NET usando um modelo de publicação/inscrever-se.Suponha primeiro, que eu tenho o seguinte contrato de serviço:

[ServiceContract(Namespace = "")]
public interface ITweetNotifier {
  [OperationContract(IsOneWay = true, 
    Action = "urn:DisplayTweet")]
  void DisplayTweet(string status);
}

E suponha que haja um aplicativo que hospeda o serviço (chamado TweetNotifierApp) que imprime apenas o texto de status entrada para a janela de console — há nada de especial sobre ele.

POSSO configurar o aplicativo host para ouvir através o barramento de serviço do .NET ao definir um ponto de extremidade usando um das ligações de retransmissão. Desde que queira implementar a publicação/assinatura (com potencialmente vários ouvintes), será Desejo usar o NetEventRelayBinding conforme ilustrado na Figura 8 .

A Figura 8 NetEventRelayBinding

<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="Default">
          <transportClientEndpointBehavior 
            credentialType="UserNamePassword">
            <clientCredentials>
              <userNamePassword 
                userName="pluralsight" 
                password="{password}"/>
            </clientCredentials>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="TweetServiceLibrary.TweetService">
       <endpoint address="sb://servicebus.windows.net/services/pluralsight/tweet"
            behaviorConfiguration="Default" 
            binding="netEventRelayBinding"
            bindingConfiguration="" 
            contract="TweetServiceLibrary.ITweetNotifier" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

Observe também que estou usando um comportamento especial que informa ao WCF quais credenciais para enviar para o serviço de controle de acesso .NET para autenticar e adquirir as declarações de barramento de serviço do .NET necessárias.Você desejará substituir o nome de usuário e senha por suas próprias credenciais se você tentar executar este exemplo.

Ao executar o aplicativo host, a infra-estrutura de hospedagem de WCF automaticamente autenticado com o serviço de controle de acesso .NET, adquire declarações e abre uma porta de saída para o barramento de serviço do .NET e registra um ouvinte no endereço especificado.Nesse ponto, o serviço hospedado localmente estará pronto para receber mensagens enviadas por meio do barramento de serviço do .NET no endereço especificado.Eu também pode procurar o endereço base da solução nesse ponto para acessar o registro de serviço feed e quaisquer pontos de extremidade escuta ativo aparecerão na alimentação.

Agora POSSO escrever um aplicativo de cliente para enviar mensagens através do barramento de serviço do .NET no mesmo endereço rendezvous.Aqui está a aparência de meu programa de cliente:

static void Main(string[] args) {
  ChannelFactory<ITweetNotifier> cf = 
    new ChannelFactory<ITweetNotifier>("tweetService");
  ITweetNotifier tweetNotifier = cf.CreateChannel();

  Console.WriteLine("Enter a status update: ");
  string status = Console.ReadLine();
  while (!status.Equals("")) {
    tweetNotifier.DisplayTweet(status);
    status = Console.ReadLine();
  }
}

Arquivo de configuração do cliente precisará aparência apenas o arquivo de configuração do host.Somente a definição do ponto de extremidade precisará aparecer dentro da seção <client>.Diferente, ele deve parecer sobre a mesma, incluindo o <transportclientendpointbehavior> configurado no ponto de extremidade do cliente.

Com isso no lugar, É possível executar várias instâncias do aplicativo host seguido por uma única instância do aplicativo cliente, e vejo todas as mensagens retransmitidas em um multicast fashion (veja a Figura 9 ).A retransmissão funcionará mesmo que o aplicativo host está atrás de um firewall ou dispositivo NAT.

A Figura 9 executar a demonstração de barramento de serviço do .NET

Isso é apenas um exemplo de muitos cenários de comunicação possíveis com suporte a barramento de serviço do .NET.Para obter mais exemplos, confira os vários exemplos de barramento de serviço do .NET fornecidos no .NET SDK dos serviços.

O serviço de fluxo de trabalho a .NET

Ao se mover em direção a nuvem de computação, o fluxo de trabalho fornece uma abordagem simplificada para coordenar interações do serviço complexo nas soluções de nuvem composto que você criar.

O serviço de fluxo de trabalho do .NET fornece um ambiente de hospedagem escalonável para executar e gerenciar fluxos de trabalho do WF na nuvem.Como o ambiente de hospedagem se baseia em janela Azure, é capaz de escala por demanda e porque o tempo de execução do WF está sendo usado, instâncias de fluxo de trabalho não são fixadas para qualquer servidor específico — eles estão livres para mover de um servidor para outro (no Windows Azure) para cada episódio de execução.O serviço de fluxo de trabalho a .NET se baseia em um serviço de persistência do WF que utiliza o Microsoft SQL Services para salvar o estado da execução de fluxos de trabalho e para garantir recursos de recuperação.

Você criar fluxos de trabalho para a nuvem usando o Visual Studio e o designer de fluxo de trabalho mesmo que você sempre usou.Você, em última análise, criar arquivos de fluxos de trabalho e regras XAML.Esses arquivos XML, em seguida, são implantados para o serviço de fluxo de trabalho a .NET onde eles podem ser usados para criar instâncias de fluxo de trabalho.

O SDK de serviços .NET inclui um modelo de projeto para criar um SequentialCloudWorkflow que é uma versão especializada do modelo SequentialWorkflow padrão.Ao definir os fluxos de trabalho a ser executado na nuvem, também há restrições sobre quais atividades que você pode usar o fluxo de trabalho.Você pode usar apenas um subconjunto das atividades na biblioteca de atividades básica do WF bem como um conjunto de novas atividades de nuvem personalizado fornecido como parte do .NET serviços SDK (veja a Figura 10 ).Essas atividades de nuvem possibilitam enviar, receber e processar mensagens, mas que é atualmente sobre ele.Mais atividades serão adicionadas no futuro versões para aprimorar os recursos do seus fluxos de trabalho com base em nuvem.

Como os outros serviços, o serviço de fluxo de trabalho a .NET vem com um portal de administração para gerenciar tipos de fluxo de trabalho e instâncias.O SDK do .NET Services também vem com um gerenciamento de cliente API que permite que você programaticamente realizar a mesma coisa.

A Figura 11 Design de fluxo de trabalho concluído

Criando um fluxo de trabalho de nuvem

Para ver como o serviço de fluxo de trabalho a .NET funciona, vamos criar um fluxo de trabalho que consome o feed Twitter público e envia a entrada mais recente para quaisquer instâncias de TweetNotifierApp inscritas por meio do barramento de serviço do .NET.

A primeira coisa que preciso fazer é criar um novo projeto de CloudSequentialWorkflow no Visual Studio 2008.Irá chamá-lo MonitorTwitterFeed.Neste ponto, você deverá ver o designer do WF tradicional.Se você expandir caixa de ferramentas atividade, você verá o conjunto restrito de atividades que você está tem permissão para usar.

Será preciso usar durante uma atividade para monitorar continuamente o Twitter pública feed a cada 60 segundos.Portanto, primeiro eu arrasto a durante a atividade para o fluxo de trabalho superfície de design e, em seguida, especificar que a condição de com seja uma condição de regra declarativa.Para fins deste exemplo, fazer a condição sempre retornará "true". Em seguida, eu arraste uma atividade de seqüência para o durante atividade para definir a seqüência de etapas que deseja repetir.

Agora, eu desejo retardar por 60 segundos, para que eu arrasta uma atividade de CloudDelay na seqüência e especificar 00:01:00 para o valor de tempo limite.E preciso recuperar o Twitter pública feed usando uma solicitação HTTP GET, para que eu colocar uma atividade CloudHttpSend logo abaixo a atividade de CloudDelay e configurá-la adequadamente (definir o método GET e a URL para http://twitter.com/statuses/public\_timeline.xml).

Em seguida, preciso ler a última entrada de status da parte superior da feed, que é possibilitado através da atividade de CloudXPathRead.Depois de colocar isso na seqüência, vincular a propriedade InXml à propriedade Response da atividade anterior.Eu também definida InXPathExpression para status/status/texto para especificar a expressão XPath.

Em seguida, preciso criar uma mensagem XML apropriada para enviar para o TweetNotifierApp através o barramento de serviço do .NET.Pode fazer isso através da atividade de CloudXPathUpdate.O serviço de destino está esperando uma mensagem que tem esta aparência:

<displaytweet> <text> status aqui </text> </displaytweet>

Portanto, depois de colocar a atividade CloudXPathUpdate na seqüência, preciso inserir o XML na propriedade InXml e "/ DisplayTweet/texto" para InXPathExpression.Também preciso vincular InNewValue à propriedade OutReadValue na atividade anterior.Isso essencialmente informa a atividade como construir um novo documento XML, inserindo um valor de entrada (o status mais recente) o modelo XML.

Finalmente, precisa instruir o fluxo de trabalho para enviar a mensagem por meio do barramento de serviço do .NET.É aí que a atividade CloudServiceBusSend entra no.Após colocá-lo no final da seqüência, defini a ação como urn: DisplayTweet, o ConnectionMode para difusão seletiva e o endereço para sb://servicebus.windows.NET/serviços/Pluralsight/tweet.Eu vincular a propriedade Body à propriedade OutXml na atividade anterior.Com isso no lugar, o fluxo de trabalho foi concluído.Veja a Figura 11 para um visual completo do design de fluxo de trabalho resultante.

Agora, para implantar e testar o fluxo de trabalho, simplesmente clique com o botão direito do mouse na superfície de design de fluxo de trabalho e selecione o fluxo de trabalho de implantação.EU digitar suas credenciais de solução e pressione implantar & executar.O suplemento irá carregar a definição de XAML para o serviço de fluxo de trabalho a .NET e inicie uma instância dele.Também é possível carregar a definição de XAML manualmente através de um formulário no portal gerenciamento.

Após você ter implantação o fluxo de trabalho, você pode procurar o portal de administração e ver o tipo de fluxo de trabalho e a instância em execução.Se você tiver quaisquer instâncias do TweetNotifierApp em execução, você verá Twitter mensagens aparecem a cada 60 segundos.

Aaron Skonnard é co-fundador da Pluralsight, uma fornecedora de treinamento oferecer tanto ministrado por um instrutor e sob demanda cursos de desenvolvedor da Microsoft.Estes dias Aaron gasta a maior parte do seu tempo de gravação Pluralsight por demanda!cursos concentrado no nuvem computação, Windows Azure, WCF e REST.Aaron anos escrever, falando e ensinando desenvolvedores profissionais em todo o mundo.Você pode contatá-lo emcontato com ele pelo site pluralsight.com / aaron.