Hoje veremos como é possível desenvolver e publicar aplicações ASP.NET no Windows Azure. Neste artigo você poderá conferir como instalar e configurar as ferramentas necessárias para que o seu Visual Studio possa criar e publicar aplicações diretamente no Windows Azure, a plataforma da Microsoft para soluções em Nuvem.
O Windows Azure é a plataforma da Microsoft para computação em nuvem. Aplicativos publicados no Windows Azure estão automaticamente disponíveis no mundo inteiro, com um alto grau de disponibilidade, segurança e principalmente escalabilidade. Isso significa que se sua aplicação for um sucesso e passar a ser acessada por milhões de pessoas, o Windows Azure dará conta do recado.
Guia do artigo:
- SQL Azure
- Site do Windows Azure
- Windows Azure Tools
- Roles no Azure
- Developer Fabric
- Habilitando uma aplicação
- Publicando uma aplicação
- Conclusão
A cada dia que passa mais e mais aplicações estão sendo distribuídas e oferecidas como serviços e não mais como simples produtos de prateleira. É o conceito de SaaS (Sofware as a Service) se tornando realidade. Isso não é diferente na plataforma .NET, onde temos o Windows Azure como uma ótima opção para soluções na nuvem. Saber como criar e publicar aplicações na nuvem é um diferencial importante para desenvolvedores da plataforma .NET.
O Windows Azure já é uma realidade desde o início deste ano de 2010. Aqui no Brasil nós também já podemos fazer uso dos serviços em nuvem da Microsoft, disponibilizados através da plataforma Windows Azure. Essa é a iniciativa da Microsoft para a computação em nuvem, que tem se tornado cada vez mais popular e presente no nosso dia-a-dia. Desde o seu correio eletrônico até aplicativos como editores de texto E planilhas estão cada vez mais sendo oferecidos como serviços, e não mais como produtos de prateleira. Agora chegou a vez das nossas aplicações, aquelas que desenvolvemos no nosso dia-a-dia para a nossa empresa ou para nossos clientes. Chegou a hora de começar a pensar em como essas aplicações podem tirar proveito da computação em nuvem. Neste artigo veremos o que é necessário instalar e configurar para que possamos utilizar o Visual Studio na criação e publicação de aplicações no Windows Azure. Veremos não apenas como criar aplicações novas, mas também como habilitar uma aplicação já existente para ser publicada no Azure.
Houve um tempo em que cada um tinha o seu próprio poço, de onde vinha a água para o consumo diário da casa, assim como também houve o tempo em que as pessoas precisavam de grandes geradores de energia movidos a diesel para ter energia elétrica em suas fazendas. Hoje, tanto a água quando a energia elétrica vêm até nós, através de canos e fios, abastecer nossas casas e dar conta das necessidades diárias que temos desses recursos. Você por acaso sabe o caminho que a energia elétrica percorre até chegar à sua casa? Todo o processo que envolve essa geração e abastecimento, desde o princípio lá na usina (provavelmente hidroelétrica) até o ponto de energia onde você liga o seu XBOX? E a água, você sabe todo o percurso que ela faz, desde os rios, passando pelas estações de tratamento, até chegar aí na torneira da pia do seu banheiro?
Não, a maioria de nós não tem nenhuma pista de como tudo isso funciona, e também não damos a mínima para isso. O fato é que consumimos água e energia elétrica, além de muitos outros recursos, sem nos preocupar de onde vem e como foi chegar ali. E aposto que você gostaria que outros recursos fossem distribuídos e oferecidos assim também. Imagine só uma linha de distribuição de cerveja, por encanamentos que iriam desde a fábrica até uma torneira aí do lado do seu sofá? Faria um sucesso enorme!
Mas o que isso tem a ver com .NET? Acontece que o princípio por trás da computação em nuvem, e por consequência o Windows Azure, é o mesmo. O que a Microsoft está oferecendo com o Windows Azure não é apenas um provedor gigante para hospedar suas aplicações, ela está oferecendo recursos de processamento e armazenamento, como se fosse energia elétrica ou água potável. São enormes data-centers distribuídos pelo mundo, no que podemos literalmente chamar de fazendas de servidores, formando uma rede enorme de hardware. Nessa gigante teia de servidores roda um sistema operacional diferente, arquitetado especialmente para funcionar em nuvem, e o qual foi chamado de Windows Azure. E é dessa enorme usina de processamento e memória que vêm os recursos que consumimos do Windows Azure. Quando usamos uma aplicação que está publicada no Windows Azure, estamos consumindo processamento e memória dessa enorme estrutura. A forma como todo esse processamento e armazenamento é cobrada de você também segue um princípio muito parecido com o dos serviços de energia elétrica e água. É basicamente de acordo com o seu consumo que será calculado o valor da sua conta. Isso tudo nos abre outros horizontes, não só na forma em como construímos nossas aplicações, mas principalmente na forma como nós vamos oferecê-las aos nossos usuários, ou deveríamos passar a chamá-los de consumidores?
Mais sobre .NET
É sobre isso que trata esse artigo. Veremos nas próximas páginas como configurar nosso ambiente de desenvolvimento com o Visual Studio e as ferramentas necessárias para construir e publicar aplicações no Windows Azure. Veremos como esse processo é bastante simples, não só para a criação de novas aplicações, mas também para habilitar aplicações já existentes para que possam ser publicadas no Windows Azure.
SQL Azure
Na edição de número 75 da .NET Magazine nós tivemos um artigo que falou sobre como utilizar o SQL Azure em aplicações construídas com NHibernate e ADO.NET Entity Framework. O SQL Azure é parte integrante da Plataforma Windows Azure, que é o foco principal desse artigo. Ele é o servidor de banco de dados da Microsoft na nuvem, e é muito parecido com o próprio SQL Server da Microsoft, nosso antigo conhecido. Aliás, se você já tem o SQL Server 2008 R2, pode se conectar ao SQL Azure através do SQL Server Management Studio e fazer uso da interface de gerenciamento de banco de dados que já conhece.
Sugiro que você leia o artigo da edição anterior que tratou desse assunto, nele vemos como utilizar o SQL Azure como banco de dados de uma aplicação ASP.NET, utilizando os principais ORMs do mercado (NHibernate e ADO.NET Entity Framework). No artigo citado você poderá ver como criar um database no SQL Azure, e principalmente como configurá-lo para poder ser acessado por sua aplicação.
O mais interessante é que o SQL Azure é muito parecido com o próprio SQL Server, o que significa dizer que basta trocarmos a string de conexão da nossa aplicação para que ela consiga funcionar no SQL Azure. É claro que alguns ajustes específicos possam ser necessários, mas em resumo o SQL Azure é compatível com o NHiberante e o Entity Framework, facilitando muito a vida de quem usa essas ferramentas.
Além disso, no decorrer deste artigo iremos utilizar o exemplo feito no artigo sobre SQL Azure para mostrar como é possível habilitar uma aplicação ASP.NET já existente para ser publicada no Windows Azure. E com isso, ao final deste artigo, você terá uma aplicação publicada no Windows Azure, utilizando um banco de dados do SQL Azure, ou seja, teremos uma aplicação ASP.NET rodando 100% na plataforma Azure.
SQL Server 2008 R2
Em abril de 2010 a Microsoft lançou o SQL Server 2008 R2. Muitos aguardaram esse novo release do SQL Server, esperando que ele fosse se chamar SQL Server 2010, como uma forma de compatibilizar os nomes dos produtos que surgiram nesse mesmo ano (Visual Studio 2010, Office 2010, SharePoint 2010 etc). Mas eis que surge a nova versão do SQL Server, ainda 2008, mas agora R2. Na seção de links desse artigo você encontrará o site principal do SQL Server 2008, onde é possível chegar aos links de download da versão gratuita do SQL Server, a Express Edition. Além de oferecer suporte à conexão com databases do SQL Azure, no SQL Server 2008 R2 temos algumas novas features muito interessantes, como: Suporte para até 256 processadores lógicos - até a versão anterior o limite era de 64 processadores; Várias melhorias no SQL Server Management Studio, que o tornam agora uma boa ferramenta para gerenciar ambientes com múltiplos servidores; e suporte à visualização de dados geoespaciais no SQL Server Reporting Services.
Site do Windows Azure
Para que você consiga fazer os testes deste artigo com o Windows Azure, será necessário adquirir um dos planos oferecidos pela Microsoft, no Microsoft Online Services, que você encontra na seção links. Confira os planos oferecidos pela Microsoft, escolha o seu e assine-o, se assim desejar. Não vou entrar em detalhes sobre como fazer isso, todas as orientações estão lá no site. Só é muito importante você notar que é um serviço pago, e que não dá para testar o exemplo final deste artigo sem uma assinatura de um destes planos. Então tome bastante cuidado e tenha certeza do plano que está adquirindo, afinal é o número do seu cartão de crédito que terá que ser informado.
Se você fez os exemplos do artigo anterior sobre o SQL Azure, e naquela ocasião contratou algum plano através do Microsoft Online Services, muito provavelmente já possui acesso ao Windows Azure. Nesse caso utilize a mesma assinatura, não havendo necessidade de você adquirir outra. Com uma assinatura em mãos, você já tem acesso ao Windows Azure, e antes de publicarmos qualquer coisa, é interessante conhecermos um pouco sobre como funciona esse portal, já que por enquanto, todo o processo de configuração e publicação é feito por aqui.
Você deve acessar o site do Windows Azure. Como você irá notar, logo na primeira página será solicitada sua credencial do Live, que ficou vinculada à sua assinatura do Windows Azure. Feito o Login, você será redirecionado para a janela principal do Windows Azure, que exibe a sua lista de “My Projects”.
Na verdade, você provavelmente verá apenas um projeto nessa lista, que corresponde diretamente ao plano do Windows Azure que você previamente contratou. Confira na Figura 1 como esse projeto irá aparecer para você. Note que nas partes embaçadas da imagem você verá a sua conta do Live, que foi utilizada na contratação do serviço. Por motivos óbvios não vou mostrar os meus dados aqui. Para prosseguir, clique sobre o seu projeto nessa lista, conforme está indicado na própria Figura 1.
Na sequência será aberta uma janela que exibe as aplicações que você já possui dentro deste projeto. Já dá pra perceber que a nomenclatura aqui não ajuda muito. O termo “Projetos” que vemos aqui nada tem a ver com os projetos do Visual Studio que estamos acostumados. Os projetos aqui são as assinaturas que você tem contratadas no Windows Azure. Dentro de cada projeto podemos ter várias aplicações, essas sim têm uma relação com uma Solution do Visual Studio, que é onde agrupamos um ou mais projetos para criar uma aplicação. Então, tome cuidado com esses nomes e não procure fazer uma relação direta entre eles e os termos que estamos acostumados a utilizar no Visual Studio.
Como é a primeira vez que estamos entrando aqui, nenhuma aplicação será listada dentro do nosso projeto. Sendo assim, para criarmos uma nova aplicação, clique em “New Service” (mais um exemplo de possível confusão de nomes), conforme você pode conferir na Figura 2.
Agora, conforme você pode ver na Figura 3, temos dois caminhos possíveis. Podemos criar uma Storage Account, que é uma alternativa ao uso do SQL Azure, onde podemos fazer uso de recursos como Azure Tables e Azure Blob. Ou podemos criar um Hosted Services, que nada mais é do que o local onde iremos publicar uma aplicação feita em .NET. Sendo assim, clique na opção Hosted Services.
Veja na Figura 4 que para criar um Hosted Services precisamos informar um “Service Label”, que servirá como um nome de referência para nosso aplicativo, e também podemos informar uma Descrição para o Serviço que será criado. Em seguida clique em Next para prosseguir.
Na página seguinte, como você confere na Figura 5, nós devemos escolher um nome global único, para formar a URL da nossa aplicação. É claro que com um redirecionamento simples podemos usar a URL que quisermos, mas é necessário que sua aplicação tenha uma URL dentro do Azure. Veja que você tem um botão que vai verificar se o nome que você quer usar está disponível.
Em seguida, nessa mesma janela precisamos definir um “grupo de afinidade” para a hospedagem do nosso serviço. Note que isso não é obrigatório, mas é aconselhável caso sua aplicação venha a utilizar outros recursos do Azure, como é o caso do SQL Azure. Sendo assim, você pode optar por usar um grupo de afinidade existente, como é o caso do meu exemplo, onde eu já tenho um grupo de afinidade na região “North Central US”. Ou você pode criar um novo grupo de afinidade, informando um nome e uma região. Lembrando que se você já tem um database no SQL Azure, escolha a mesma região utilizada lá. Feito isso, você deve clicar em Create e aguardar alguns instantes enquanto o serviço é criado.
Na Figura 6 você pode conferir o serviço já criado. Se você chegou até essa tela, já está apto a publicar suas aplicações no Windows Azure. Mantenha essa janela aberta, pois iremos voltar a ela mais tarde. Agora vamos partir para a criação de uma primeira aplicação para ser publicada no Azure.
Windows Azure Tools
Nos exemplos desse artigo irei utilizar o Visual Studio 2010, e não há motivos para você não utilizá-lo, já que você pode construir aplicações para o Azure com a versão Express do Visual Studio 2010, o Visual Web Developer. Com o Visual Studio instalado e aberto, vá até a opção File / New Project, para tirarmos uma dúvida importante. Como você pode ver na Figura 7, por default temos um grupo de templates chamado Cloud.
Note que o único template que temos aqui é o “Enable Windows Azure Tools”, o que significa que o Windows Azure Tools não está instalado no seu computador, e portanto não podemos criar aplicações para a plataforma. O Windows Azure Tools é o conjunto de ferramentas e templates necessários para que possamos criar e testar aplicações feitas para a plataforma Windows Azure. Se você criar uma aplicação com esse template, irá apenas criar um projeto vazio que irá abrir a tela que você vê na Figura 8.
Porém, temos uma opção mais interessante para a instalação do Windows Azure Tools, chamada Microsoft Web Platform Installer. Essa ferramenta de instalação da Microsoft facilita a vida do desenvolvedor Web, já que centraliza em uma única ferramenta a instalação e configuração de uma série de produtos e ferramentas necessárias para o desenvolvimento de aplicações Web, incluindo o Windows Azure Tools. Sendo assim, pegue na seção de links a URL para o download do Microsoft Web Platform Installer. Confira na Figura 9 o site de onde você pode fazer o download desse instalador.
Assim que você baixar, execute o Web Platform Installer para instalarmos o Azure Tools. Veja na Figura 10 a tela principal do Web Platform Installer. Como você pode ver ele mostra nessa tela as novidades que temos para desenvolvimento Web. E também note que esse instalador abrange praticamente todas as vertentes de desenvolvimento Web da Microsoft.
Nessa primeira tela do Web Platform Installer, clique no link Options que temos no canto inferior esquerdo. Como você confere na Figura 11, nessa tela de opções precisamos habilitar a opção Enterprise, que é onde iremos encontrar o Windows Azure Tools.
Com isso, vá até a aba Developer Tools e clique na opção “Click to include the recommended products” e em seguida clique em Install, como nos mostra a Figura 12. Adicionalmente, se você quiser aproveitar, dê uma olhada nas demais opções do Web Platform Install, onde você vai encontrar ferramentas importantes como o Silverlight Tools.
Na Figura 13 você vê o resumo das ferramentas que serão instaladas e também pode ver a importância de usar o Web Plataform Installer. Note que o instalador identificou que existe uma dependência importante no Windows Azure Tools. Para instalar o Azure Tools é necessário instalar também o Windows Azure SDK. Isso será feito automaticamente pelo Web Platform Installer. Basta clicar em I Accept e aguardar o término das instalações.
Após o término dos downloads, o setup de instalação do Windows Azure Tools será iniciado, conforme você pode ver na Figura 14. Basta seguir esse Wizard até o final, para que o Azure Tools seja instalado. E com isso já temos o Windows Azure Tools instalado e já podemos criar aplicações para o Azure no Visual Studio 2010.
Roles no Azure
Agora que temos todas as ferramentas necessárias devidamente instaladas, vamos criar nosso primeiro exemplo prático no Windows Azure. Depois de todas as instalações realizadas, um reboot no seu computador é uma boa pedida. Abra em seguida o seu Visual Studio 2010 e vá novamente até a opção File / New Project. Selecione a seção Cloud e veja que agora temos o template “Windows Azure Cloud Service”, como você pode ver na Figura 15. Selecione esse template, escolha um nome para a sua solução e clique em Ok. Em seguida irá aparecer uma segunda janela onde devemos escolher quais Roles queremos incluir em nossa Solução. Veja que as Roles são divididas em três grupos, que são as linguagens Visual Basic, Visual C# e Visual F#.
Uma Role do Windows Azure é praticamente como um Projeto do Visual Studio, a diferença é que a Role é um projeto com “Windows Azure já habilitado”. Veja que temos Roles específicas para tipos de projetos já conhecidos no Visual Studio. Temos uma Role chamada ASP.NET Web Role, que deve ser utilizada para criar um projeto ASP.NET Web Forms no Windows Azure. Já o ASP.NET MVC 2 Web Role é para a criação de uma aplicação ASP.NET MVC, também compatível com o Azure. Temos ainda um WCF Service Web Role, para publicação de serviços WCF no Windows Azure. Uma Worker Role, utilizada para a criação de uma aplicação que rodará processos em Background. E o CGI WebRole, usado para hospedar aplicações FastCGI.
FastCGI
FastCGI é um protocolo que faz a ponte entre programas interativos com um servidor Web. FastCGI é uma variação do antigo CGI (Common Gateway interface). O principal objetivo do FastCGI é reduzir o overhead associado com a comunicação entre programas CGI e o servidor Web. Basicamente, o FastCGI permite que o servidor gerencie mais do que uma requisição de página de uma única vez. Alguns dos servidores Web que suportam CGI são: o Microsoft IIS (Internet Information Services), o Apache HTTP Server (suporta parcialmente), Abyss Web Server, Cherokee HTTP Server, Kerio WebStar, LiteSpeed Web Server, Sun Java System Web Server, Zeus Web Server, entre outros.
Neste exemplo vamos escolher o ASP.NET Web Role, conforme você pode ver na Figura 16. Note que podemos criar uma solução com várias Roles, e também podemos renomear as Roles que serão criadas. Clique em OK para concluir.
Developer Fabric
Agora que nossa solution foi criada com a Role do ASP.NET Web Forms, vamos fazer nosso primeiro exemplo. Veja na Figura 17 que na Solution Explorer temos dois projetos. O projeto AzureExemplo1 é um projeto do Tipo ASP.NET Web Forms comum, onde podemos criar nosso site da mesma forma como fazemos em projetos ASP.NET Web Forms que já estamos acostumados. Já o projeto AzureTeste1 é como o “Host” do Windows Azure, onde temos as Roles configuradas.
O exemplo que iremos fazer é realmente muito simples, como você pode conferir na página Default.aspx, aqui na Figura 18. Veja que apenas incluímos um Button e um Label, e o código do botão podemos ver na Listagem 1.
protected void Button1_Click(object sender, EventArgs e)
{
Label1.Text = string.Format("Hoje é dia: {0} e agora são: {1}",
DateTime.Today, DateTime.Now.ToShortTimeString());
}Veja que o código simplesmente irá exibir no Label a Data e Hora em que o usuário clicou no botão. É claro que estamos fazendo esse exemplo simples apenas para podermos ver o comportamento da aplicação quando é executada na máquina do desenvolvedor. Sendo assim, salve, compile e execute o projeto, e você certamente irá receber a mensagem de erro que pode ver aqui na Figura 19.
Essa mensagem nos diz que para conseguir executar o Development Fabric é preciso executar o Visual Studio com permissão de administrador. O Development Fabric é um dos componentes instalados com o Windows Azure Tools que foi instalado há pouco. Já iremos ver em maiores detalhes como o Development Fabric funciona e qual é o papel dele no desenvolvimento de aplicações para o Azure.
Para que possamos executar o Visual Studio 2010 com permissão de administrador, clique com o botão direito sobre ele e escolha a opção “Run as Administrator”. E agora sim podemos executar o nosso projeto de exemplo. A primeira coisa que você irá notar quando executar a aplicação é que ela irá demorar um pouco mais para iniciar do que demoraria uma aplicação ASP.NET comum. Essa demora é comum, já que nesse processo é iniciado o Development Fabric, citado há pouco. Como você pode ver na Figura 20, a aplicação é executada normalmente e aberta no Internet Explorer. Note que a aplicação é executada no endereço de IP da máquina local (127.0.0.1), e na porta 81.
É nessa porta 81 onde está sendo executado o Development Fabric, que é onde foi feito o deploy da Web Role ASP.NET. O Development Fabric é o cara responsável por fazer o papel da infraestrutura do Windows Azure na máquina do desenvolvedor. Na prática é ele que faz o papel do Windows Azure quando executamos ou debugamos uma aplicação no Visual Studio. O Development Fabric, como foi dito anteriormente, é iniciado quando pedimos para executar a aplicação, e podemos acessar o seu console através do System Tray do Windows, como você pode conferir na Figura 21.
Como você pode ver, além do Development Fabric, também temos o Development Storage, que aqui faz o papel do Azure Tables e Azure Blob, os repositórios não relacionais do Windows Azure. Na Figura 22 você pode ver o Web Role executando dentro da Console do Development Fabric.
Habilitando uma aplicação existente no Azure
Como você pode ver não há muitos segredos no processo de desenvolvimento de aplicações para o Windows Azure. Basta utilizar os seus conhecimentos já existentes, de acordo com a WebRole que você escolheu. Então não vamos nos estender aqui em um exemplo muito elaborado de uma aplicação ASP.NET. Ao invés disso vamos ver agora como habilitar uma aplicação já existente, feita anteriormente em ASP.NET, na plataforma Windows Azure. Sim, isso é possível e sem muita dificuldade. A aplicação que iremos utilizar para fazer esse exercício será a mesma aplicação desenvolvida no artigo que falou sobre o SQL Azure. Assim, ao final desse exemplo teremos uma aplicação ASP.NET rodando 100% no Windows Azure.
Só relembrando um pouco, a aplicação feita no artigo do SQL Azure foi uma pequena parte de uma aplicação sobre Aluguel de Imóveis. Esse exemplo foi feito usando o NHibernate e o ADO.NET Entity Framework, justamente para mostrar que essas duas ferramentas são compatíveis com o SQL Azure. Não vamos entrar nos detalhes de implementação dessa aplicação, e se você desejar entender melhor como foi feito esse desenvolvimento, sugiro a leitura do artigo citado.
Dito isso, vamos abrir essa aplicação no Visual Studio 2010, lembrando que o Visual Studio deve ser executado com permissão de administrador. Relembrando mais um ponto importante do artigo sobre o SQL Azure, a única mudança que foi necessária na aplicação para que ela pudesse acessar o banco de dados no SQL Azure foi a connection string. Isso tanto para o NHibernate quanto para o ADO.NET Entity Framework. Veja na Listagem 2 a configuração da String de Conexão que aponta para o SQL Azure, em um arquivo de configuração do NHibernate (hibernate.cfg.xml).
<?xml version="1.0"?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.driver_class">
NHibernate.Driver.SqlClientDriver
</property>
<property name="hbm2ddl.auto">update</property>
<property name="show_sql">true</property>
<!-- Connection String para SQL Server Local
<property name="connection.connection_string">
Server=localhost;initial catalog=Alugo;Integrated Security=True
</property>
-->
<!-- Connection String para SQL Azure –
troque os dados de servidor, database, usuário e senha -->
<property name="connection.connection_string">
Server=myServer;Database=Alugo;User
ID=myUser;Password=myPassword;Trusted_Connection=False;Encrypt=True;
</property>
...Agora, para podermos habilitar essa aplicação para poder ser publicada no Windows Azure, vá até a janela Solution Explorer, clique com o botão direito sobre a solução e escolha a opção Add / New Project. Assim como foi mostrado lá na Figura 15, selecione o template Windows Azure Cloud Service, informe um nome para o projeto (nesse exemplo foi usado AlugoCloud) e clique em Ok. Na janela seguinte, onde deveríamos escolher as Roles do Azure, agora nós não vamos selecionar nenhuma Role, vamos apenas clicar em Ok, como mostra a Figura 23.
Nós não escolhemos nenhuma Role porque na verdade vamos definir a aplicação ASP.NET já existente como a Web Role da nossa solução. Veja na Solution Explorer que agora temos o projeto Azure AlugoCloud. Clique com o botão direito sobre a pasta Roles, e vá até Add / New Web Role Project in Solution (Figura 24).
Essa opção serve para registrarmos algum projeto Web já existente, como sendo uma Web Role do Azure. Veja na Figura 25 que a janela que é aberta lista todos os projetos Web existentes na Solução aberta. No nosso caso o único existente é o nosso projeto Alugo.AspNet. Clique em Ok para registrá-lo como uma Web Role. Feito isso, agora na Solution Explorer você pode conferir que o projeto ASP.NET foi registrado como a WebRole da nossa solução, confira na Figura 26.
Acredite ou não, já podemos testar nossa aplicação no Development Fabric, e conferir se ele funciona dentro do ambiente do Windows Azure. Antes de você fazer este teste, vamos lembrar que essa aplicação de exemplo pode ser executada tanto com o NHibernate quanto com o Entity Framework. Para podermos configurar isso tudo, foi utilizada uma classe ServiceLocator, que em conjunto com a ferramenta Windsor, nos permite fazer a Inversão de Controle (IoC), mantendo as camadas de Domínio e Repositório totalmente desacopladas. O que ganhamos com isso é a possibilidade de termos duas camadas de repositórios distintas, usando ferramentas diferentes em cada uma delas (NHibernate e Entity Framerowk). Apenas para lembrarmos, vamos ver na Listagem 3 como essa configuração é feita na classe ServiceLocator.
using Alugo.Dominio.IRepositorios;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using CommonServiceLocator.WindsorAdapter;
using Microsoft.Practices.ServiceLocation;
namespace Alugo.AspNet
{
public class ServiceLocatorProvider
{
public static void Initialize()
{
var container = new WindsorContainer();
// NHIBERNATE
container.Register(Component.For(typeof(IRepositorioHelper))
.ImplementedBy(typeof(Repositorio.Nhibernate.Helper))
.LifeStyle.Transient);
container.Register(Component.For(typeof(IRepositorio<>))
.ImplementedBy(typeof(Repositorio.Nhibernate.Repositorio<>))
.LifeStyle.Transient);
// ENTITY FRAMEWORK
//container.Register(Component.For(typeof(IRepositorioHelper))
// .ImplementedBy(typeof(Repositorio.EntityFramework.Helper))
// .LifeStyle.Transient);
//container.Register(Component.For(typeof(IRepositorio<>))
// .ImplementedBy(typeof(Repositorio.EntityFramework.Repositorio<>))
// .LifeStyle.Transient);
var sl = new WindsorServiceLocator(container);
container.Register(Component.For<IServiceLocator>().Instance(sl));
ServiceLocator.SetLocatorProvider(() => sl);
}
}
}IoC com Windsor
IoC é a sigla para Inversion of Control ou Inversão de Controle. Inversão de Controle é uma forma de se aplicar a Injeção de Dependência em uma aplicação desenvolvida em camadas. Injeção de dependência é um padrão de desenvolvimento utilizado na orientação a objetos quando queremos manter baixo o nível de acoplamento entre diferentes partes de uma aplicação. A inversão de Controle é facilmente aplicada com a ajuda de um Container de IoC, ou ferramentas que fazem a Inversão de Controle, dando a oportunidade de você configurar a “amarração” que determina como as partes ou camadas da aplicação irão se comunicar. Para que seja possível aplicar a Injeção de Dependência e por consequência poder adotar uma ferramenta de IoC, é necessário que a aplicação seja arquitetada com a adoção de Interfaces, que determinam como as camadas devem se comunicar. Sendo assim, um container de Inversão de Controle é uma ferramenta que registra qual classe concreta deverá ser utilizada toda vez que pedirmos por uma Interface específica.
Veja que nesse exemplo nós configuramos o NHibernate como sendo a camada de Repositório da nossa aplicação. Caso você queira fazer o mesmo teste com o ADO.NET Entity Framework, bastará modificar essa configuração no ServiceLocator. Nesse momento você pode fazer um teste executando a aplicação em sua máquina, lembrando apenas de configurar a Connection String, de acordo com o banco de dados que você quer utilizar para fazer este teste (seja ele local ou no SQL Azure). Se você estiver usando o NHibernate deverá configurar essa connection string no arquivo hibernate.cfg.xml, como já foi mostrado na Listagem 2. Caso esteja fazendo um teste com o Entity Framework, deverá configurar a Connection String no arquivo Web.config, como você pode ver na Listagem 4.
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<!-- Connection String para SQL Server Local
<add name="AlugoConnectionString"
connectionString="data source=(local);initial catalog=Alugo;Integrated Security=True"
providerName="System.Data.SqlClient" />
-->
<!-- Connection String para SQL Azure –
troque os dados de servidor, database, usuário e senha -->
<add name="AlugoConnectionString"
connectionString="Server=myServer;Database=Alugo;User
ID=myUser;Password=myPassword;Trusted_Connection=False;Encrypt=True;"
providerName="System.Data.SqlClient" />
</connectionStrings>
…Se você fizer um teste com uma string de conexão correta, poderá ver a aplicação rodando na sua máquina local, conforme podemos conferir aqui na Figura 27. Note que antes de publicar a aplicação no Windows Azure, é importante ter certeza que ela funciona corretamente no Development Fabric.
Como você pode ver esse exemplo está rodando no Development Fabric, e acessando um database no SQL Azure. Note que o exemplo tem a opção de criar o database, função que pode ser realizada tanto pelo NHibernate quanto pelo ADO.NET Entity Framework. E o cadastro de Proprietários pode ser usado para testarmos todas as operações CRUD. Feito isso já podemos fazer nossa primeira publicação no Windows Azure.
Publicando uma aplicação no Windows Azure
Já vimos como criar uma nova aplicação para o Windows Azure e também como habilitar uma aplicação já existente para trabalhar nele. Agora vamos ver como publicar uma aplicação no Windows Azure, e faremos isso com esse exemplo da aplicação de Aluguel de Imóveis. Antes de fazermos a publicação de fato, precisamos alterar uma pequena configuração do Development Fabric. Clique com o botão direito sobre o projeto AlugoCloud, e vá até a opção Properties. Como você pode ver na Figura 28, veja que na aba Development temos uma propriedade chamada “Start Development Storage services”, que inicialmente vem configurada como True. Essa propriedade deve ser configurada como False antes de fazermos a publicação no Windows Azure, para que a aplicação não faça uso dos serviços de storage do Development Fabric, e sim do próprio Azure.
E agora, para publicarmos nossa aplicação no Windows Azure, clique novamente com o botão direito sobre o projeto AlugoCloud e escolha a opção Publish, como você pode ver na Figura 29.
Isso irá abrir uma janela (Figura 30) que nos permite publicar a nossa aplicação de duas formas possíveis. Podemos simplesmente criar um pacote de distribuição e usar o site do Windows Azure para completar a publicação, ou podemos fazer o Deploy direto no Windows Azure, identificando aqui a nossa credencial do Windows Azure.
Nesse exemplo vamos criar um pacote de distribuição e fazer o deploy direto pelo site. Faremos assim, pois dessa forma não precisaremos de um certificado de autenticação para fazer a publicação, o que simplifica um pouco o processo. Mas é claro, que se você planeja ter uma aplicação real no Windows Azure, é interessante que você faça essa configuração para realizar a publicação pelo Visual Studio, o que pode automatizar o processo.
Para prosseguir, selecione a opção “Create Service Package Only”, e clique em Ok. O resultado desse processo de publicação é aberto no Windows Explorer e consiste em dois arquivos (Figura 31). Um arquivo chamado AlugoCloud.cspkg, que é o pacote que contém todo a aplicação (se você trocar a extensão desse arquivo para .zip, poderá ver como é esse conteúdo). O outro arquivo é o ServiceConfiguration.cskfg, que é um arquivo de configuração para o Windows Azure.
Com isso agora temos que voltar lá no site do Windows Azure para finalizar a publicação. Mais especificamente na página que chegamos lá na Figura 6. E quando você chegar nessa página, clique no botão Deploy. Na página que será aberta, temos que informar o caminho do arquivo AlugoCloud.cspkg, e também do arquivo ServiceConfiguration.csfg, assim como você vê na Figura 32.
Informe um Label de identificação para esse Deploy e mantenha as configurações default do Sistema Operacional, que para esse exemplo não nos interessa. Depois, é importante que você entenda mais a fundo o que são essas configurações, que você pode conferir pelos links de ajuda que temos nessa mesma página. Para finalizar clique em Deploy. Esse processo, como você poderá verificar, poderá demorar alguns minutos, que vai depender do tamanho do seu pacote. Enquanto o Deploy é feito, você verá uma informação de progresso, parecida com a que vemos aqui na Figura 33.
Quando esse processo terminar, veremos a tela que temos aqui na Figura 34. Note que a aplicação está com o Status “Stopped”, o que significa que apesar do deploy ter sido realizado com sucesso, ela ainda não está rodando no Windows Azure. Note também que o aviso em amarelo nos diz que apesar de a aplicação ainda não estar rodando no Azure, o “taxímetro” já está rodando a partir desse momento, o que significa que você será cobrado a partir desse momento pela Microsoft.
A partir daqui também podemos ver qual é a URL que nossa aplicação poderá ser acessada e também um ID que identifica esse Deploy. E também é a partir daqui que conseguimos realizar operações como Upgrade, Configuração da Aplicação e do Sistema Operacional, Deleção da Aplicação e a Execução da Aplicação, que é o que faremos ao clicar no botão Run. Esse processo também deverá demorar alguns instantes, e ao término veremos a mudança do status do nosso projeto, mostrado aqui na Figura 35.
Note que a aplicação ainda está em modo de inicialização, o que indica que ela ainda não está pronta para o uso. Esse é um processo que poderá demorar um pouco mais de tempo, e esse status ainda poderá mudar para “Busy”, antes de ser finalizado e apresentar o status de “Ready”, como vemos na Figura 36.
Sua aplicação está agora distribuída e funcionando no Windows Azure, e se você acessar a URL poderá conferi-la no browser, como vemos aqui na Figura 37. Essa aplicação está publicada e rodando no Windows Azure, acessando um banco de dados no SQL Azure.
Como você pode notar eu não disponibilizei aqui a URL dessa aplicação, porque eu a tirei do ar ao término desse artigo, justamente para que a Microsoft não gerasse nenhuma cobrança adicional por esse exemplo. Aliás, não se esqueça de que para interromper a cobrança do serviço você deve suspender a aplicação, através da opção Suspend que você vê na Figura 36, e em seguida através da opção Delete que será habilitada.
Conclusão
Como você pôde ver, o Windows Azure não é nenhum bixo de sete cabeças. É muito fácil criar novas aplicações para o Azure, assim como habilitar aplicações já existentes para trabalhar no Windows azure. Talvez não seja tão fácil assim o processo de configuração e deploy no site do Windows Azure, mas certamente isso deverá ser melhorado com o tempo. O importante é que esse serviço já está no ar, e você já está apto a usar o Windows Azure como uma opção para a computação em nuvem.
