Consumindo serviços WCF em Silverlight

Olá a todos,

                Nesse post vamos apresentar como consumir serviços WCF a partir de uma aplicação desenvolvida em Silverlight. Antes de apresentarmos o exemplo vamos lembrar algumas questões relacionadas a esse cenário e apresentar algumas diferenças entre consumir um serviço através de uma aplicação escrita em Silverlight e aplicações desenvolvidas em outras tecnologias.

                A primeira questão é porque a aplicação deve ser desenvolvida em Silverlight? Na plataforma Microsoft podemos desenvolver nossas aplicações Web utilizando ASP.Net, tanto no modo tradicional como através do modelo MVC, ou em Silverlight. Para aplicações simples que não necessitem de uma interface rica com o usuário é recomendável o uso do ASP .Net na forma tradicional devido a sua simplicidade e velocidade de construção. Para camadas de apresentação com lógica mais complexa, cujos componentes podem ser reaproveitados para simplificar a solução e reduzir o tempo de desenvolvimento, porém a interatividade com o usuário continua simples é recomendado o modelo MVC. A tecnologia Silverlight é recomendada quando precisamos de uma aplicação Web com uma interface rica, com recursos próximos de uma aplicação Desktop.

                Uma segunda questão é onde desenvolveremos nossas regras de negócio. Embora seja possível escrever regras de negócio, acessarmos base de dados e outros recursos com o uso de Silverlight não temos disponíveis nessa tecnologia todos os recursos da plataforma .Net. Além dessa restrição técnica devemos lembrar que é boa prática separarmos a camada de negócio da camada de apresentação. Essa separação nos permite reaproveitar funcionalidades e simplifica a solução além de permitir a evolução das camadas de forma independente.

Na plataforma Microsoft podemos desenvolver nossa camada de negócio utilizando componentes COM+, Web Services ASP.Net ou Serviços WCF. O COM+ é uma tecnologia madura, porém seu uso restringe a integração de nossas aplicações somente a sistemas desenvolvidos para a plataforma Microsoft. Essas restrição ocorre pois essa tecnologia utiliza um protocolo de comunicação proprietário. Os Web Services ASP .Net  são simples de desenvolver, porém permitem comunicação apenas através do protocolo Http na porta 80 e tem poucos mecanismos de segurança . A tecnologia WCF, entretanto, nos permite desenvolver aplicações que disponibilizam suas funcionalidades através de diversos protocolos de comunicação em diferentes endereços, além de possuir um mecanismo de segurança mais robusto que os Web Services ASP .Net.

              Aplicações escritas em Silverlight não podem utilizar componentes COM+, pois essa tecnologia não é suportada em Silverlight. Outro motivo para o não uso de COM+ nessa tecnologia é que aplicações escritas em Silverlight são executadas na máquina cliente, onde não podemos registrar componentes. Portanto quando utilizamos Silverlight ficamos restritos aos Web Services ASP .Net ou a serviços WCF. Ao utilizarmos Web Services ASP.NET somos obrigados a instalar o IIS no nosso servidor de aplicação, porém quando utilizamos serviços WCF podemos utilizar Windows Services ou no WAS (disponível somente no Windows 2008) para hospedar nossos serviços. Uma outra vantagem no uso de serviços WCF é a possibilidade de utilizarmos bindings que trafegam as mensagens em formato binário, melhorando a performance da aplicação.

                Quando utilizamos aplicações Silverlight para consumir serviços WCF temos três principais diferenças em relação a ASP .Net ou aplicações Desktop. A primeira diferença é sobre os bindings utilizados: em silverlight é possível utilizarmos somente os bindings BasicHttpBinding e o CustomBinding, enquanto nas outras tecnologias é possível utilizarmos todos bindings disponíveis. A segunda diferença está na chamada dos métodos e chegada do resultado: em Silverlight o consumo de serviços WCF é sempre assíncrono, enquanto nas outras tecnologias é possível consumirmos serviços de forma síncrono ou assíncrona. A última diferença é sobre o consumo de serviços WCF que estão em outro domínio. Nessa situação é necessária a inclusão de dois arquivos no servidor em que são executados os serviços para permitir que essas aplicações sejam acessadas por consumidores que estão e outros domínios.

                Passaremos agora para a construção do nosso exemplo. Nesse exemplo teremos na mesma solução um projeto do tipo Silverlight Application, que será nossa camada de apresentação, e uma aplicação ASP .Net que hospedará tanto nossa aplicação Silverlight como o serviço WCF. Começaremos essa estrutura adicionando o projeto Silverlight. Após selecionado o tipo de projeto e informado o seu nome e caminho o template nos questiona se desejamos que seja criado um Web Site ou Web Application Project. Para esse exemplo utilizaremos um Web Site:

Iniciando o projeto

Criando o projeto Web

 Ao executarmos pela primeira vez nossa solução nos é informado que o arquivo Web.Config não está configurado para suportar o Debug da aplicação Web. Deixando a primeira opção selecionada o Visual Studio fará as modificações necessárias nesse arquivo para permitir o debu. Após clicar no botão OK dessa janela será iniciada a aplicação Web que hospeda o projeto Silverlight e nesse momento será aberta um Internet Explorer (ou o internet browser configurado como default no visual Studio) com a página em branco. Nessa página está nossa aplicação Silverlight que no momento não contém nenhum controle ou ação.

Hablitando o projeto Web para debug

O último passo para montar a estrutura inicial é adicionar o Serviço WCF. Para isso clique com o botão direito sobre o projeto Web (não o projeto Silverlight) e selecione a opção Add New Item. Será aberta a janela semelhante a da imagem abaixo. Selecione a opção Silverlight-enabled WCF Service e informe um nome para seu serviço. Note que após adicionar o serviço será criado um arquivo com a extensão .svc que contém um outro arquivo com a extensão .cs. O arquivo .cs é a implementação do serviço WCF e o arquivo .svc é o arquivo necessário para hospedarmos nosso serviço no IIS.

Adicionando o servico WCF

            Passaremos agora para o desenvolvimento do serviço que terá apenas um método que fará uma pesquisa em uma lista de nomes. O método que realiza a pesquisa receberá uma string e retornará todos os nomes que comecem que essa string. Para simplificar a solução nossa lista de nomes é montada hard-coded toda vez que a classe do serviço é instanciada para evitar complexidades que não são o foco desse post.

           Para os leitores que não estão familiarizados com o código, a pesquisa pelos nomes é realizada através de uma query LINQ. Essa tecnologia, que será assunto de muitos outros posts, nos permite realizar pesquisas em coleções de objetos, XMLs, banco de dados e outras fontes de dados.

Codigo do servico

             Criado nosso serviço, vamos referenciá-lo na nossa aplicação Silverlight. Para criar essa referência devemos selecionar o projeto Silverlight e clicar com o botão da direita e selecionar a opção Add Service Reference. Será aberta uma tela para informamos o endereço do serviço que queremos adicionar a referencia. Como nosso serviço está na mesma solução do projeto Silverlight basta clicar no botão Discover. O campo com o endereço do serviço e a lista serão preenchidos com as informações do nosso serviço. Basta selecioná-lo e informar um namespace adequado e em seguida clicar no botão OK.

Adicionando a referencia do servico

Descobrindo as configuracoes do servico

No final desse processo poderá aparecer a janela de erro da imagem abaixo, que pode ser ignorada.

Mensagem de erro

               O próximo passo é desenvolver a interface da aplicação Silverlight. Nesse exemplo adicionamos uma caixa de texto para o usuário informar o início do nome, um botão para disparar a pesquisa e uma lista que recebe o resultado da pesquisa:

XML da aplicacao Silverlight

            Vamos finalmente desenvolver o código para a aplicação Silverlight consumir o serviço WCF e exibir o resultado da pesquisa. O primeiro passo é declarar e criar uma instância da classe Proxy gerada pelo Visual Studio quando adicionamos a referência do serviço. Como o consumo do serviço é assíncrono quando o Proxy receber a resposta do serviço ele disparará um evento. Portanto antes de realizarmos a chamada devemos informar para o Proxy qual o método que deve ser disparado com a resposta do serviço. O nome do EventHandler que deve receber o método a ser disparado é formado pelo nome do método seguido do sufixo “Completed”. A melhor maneira de realizar essa tarefa é criar uma nova instancia do EventHandler, pois o Visual Studio sugere o restante do código. Criada essas estrutura podemos chamar o método do serviço, cujo nome de método no Proxy é formado pelo nome do método seguido do sufixo “Async”. Nada impede de realizarmos essas duas últimas tarefas na ordem inversa, primeiro realizar a chamada para em seguida criar o EventHandle, porém caso ocorra algo na maquina que executa a aplicação Silverlight (máquina cliente) que cause uma lentidão na execução da próxima linha de código a ponto da resposta do serviço chegar antes essa resposta será perdida.

                Devemos nos atentar para o período entre o envio da chamada do método e a chegada da resposta na aplicação cliente. Essa atenção é necessária pois o consumo é assíncrono e durante o período mencionado o usuário poderá tomar algumas ações indesejadas, que podem até causar mal funcionamento da aplicação. Portanto temos que verificar quais ações podem ser realizadas pelo usuário e bloquear as demais. Recomendo adicionar também algum sinal de que a aplicação está esperando o resultado do serviço para não dar a impressão para o usuário que a aplicação “travou”.

Codigo que consome o servico WCF

A parte final do código é passar o resultado da pesquisa para a lista. Essa tarefa é realizada no método que é disparado pelo Proxy após o recebimento da resposta do serviço. Nesse método simplesmente passamos o resultado do método a listbox. O valor de retorno dos métodos de serviços sempre são obtidos através da propriedade Result e os parâmetros passados por referencia ou de output também estão disponíveis no objeto através de propriedades com os seus nomes.

Nesse ponto temos uma aplicação desenvolvida em Silverlight consumindo um serviço WCF. Lembro que nesse exemplo toda a solução é executada no mesmo domínio, dispensando a configuração para consumo de serviços em domínios diferentes do da aplicação. Esses arquivos serão abordados no próximo post sobre Silverlight.

Como sempre deixei uma cópia do exemplo criado no post no meu Sky Drive, com o nome SilverlightWCF.

Abraço a todos e até o próximo post.

Cenários WCF: Configurações dinâmicas

Olá a todos,

                Depois de um descanso voltamos para o nosso blog. Nesse post vamos falar sobre como configurar e hospedar serviços WCF dinamicamente. O resultado desse post será um Windows Service capaz de hospedar serviços WCF dinamicamente, sem a necessidade de adicionar as referências dos serviços no projeto. Outra característica é que todas as configurações serão centralizadas em banco de dados. O resultado da centralização das configurações é um catálogo dos serviços que temos em nosso ambiente além desses serviços serem facilmente reconfigurados. Nesse post abordaremos também um ponto interessante do WCF: podemos ter os métodos de uma mesma instância de um serviço expostos através de diferentes endpoints, que podem ser utilizados por diferentes aplicações ou clientes.

                Esse projeto pode ser utilizado para diversas finalidades. Nos ambientes de testes e produção evitamos a explosão (grande número) de Windows Services hospedando nossas aplicações WCF e centralizamos as configurações de todos os serviços e suas instâncias, facilitando a administração desses recursos. No ambiente de desenvolvimento esse projeto reduz a necessidade de escrevermos hosts específicos para cada projeto, seja para testes ou para depuração.

                Vamos então para o desenvolvimento da aplicação. Primeiro criamos um projeto do tipo Windows Service (HostGenerico), que será a aplicação que hospedará os serviços, em seguida adicionamos mais dois projetos do tipo WCF, que utilizaremos para testar as funcionalidades do projeto. Note que não adicionamos ao projeto do Windows Service as referências das aplicações WCF.

Estrutura da solucao

                O próximo item a ser criado é o banco de dados. Nossa aplicação utilizará esse banco de dados para recuperar as configurações e criar dinamicamente as instâncias dos serviços e endpoints configurados para cada servidor. A aplicação poderá criar diversos endpoints para o mesmo serviço, onde cada um desses endpoints poderá utilizar endereço e binding específico e diferente dos demais para expor as funcionalidades do serviço.

                Na tabela chamada Binding são cadastrados os bindings que podem ser utilizados pelos serviços que serão hospedados por nossa aplicação. Nessa tabela o campo Nome é utilizado para identificarmos cada tipo de binding facilmente enquanto o campo Classe será utilizado pela aplicação para criar dinamicamente, através de Reflection, uma instância do tipo do binding. Uma observação importante nesse ponto é que o conteúdo do campo Classe deve ser o AssemblyQualifiedName e não seu FullName, pois a DLL que contém os bindings do WCF (System.ServiceModel.dll) está registrada no GAC. Para bindings customizados (CustomBindings) cujas DLLs não forem registradas no GAC esse campo poderá ser o FullName.

                Utilizamos a tabela Servidor para cadastrarmos quais servidores podem hospedar os serviços WCF através do nosso projeto, lembrando que esses servidores devem possuir uma cópia da aplicação. O nome do serviço é utilizado pela aplicação para recuperar todas as configurações registradas para o computador onde ela está sendo executada. O campo Ativo indica para a aplicação se as configurações para determinado servidor devem ser carregadas ou não.

                Na tabela Servico temos todos os serviços que podem ser hospedados por nossos servidores através da aplicação. Nessa tabela o campo Nome serve para identificarmos e diferenciarmos nossos serviços. O campo Arquivo possui o nome completo do arquivo que contém as informações do nosso serviço (Contrato e Classe). A aplicação carrega dinamicamente o Assembly desse arquivo através de Reflection, portanto o servidor que hospeda determinado serviço deve ter uma cópia desse arquivo. Carregado o Assembly, a aplicação utiliza o campo Classe para carregar dinamicamente o tipo do serviço e o campo Contrato para carregar o tipo do contrato que serão utilizados para criar o serviço e os endpoints respectivamente. O campo EnderecoMetaDados é utilizado pela aplicação para criar um endpoint que expõem os Meta Dados do serviço, para o serviço não expor essa informação basta deixar esse campo como nulo.

                A tabela endpoint é utilizada para cadastrarmos quais endpoints devem ser criados para cada serviço em cada servidor. Na coluna endereço temos o endereço do endpoint e através das colunas CodigoBinding e CodigoServico obtemos as configurações do tipo de binding do serviço respectivamente.

Abaixo temos o diagrama do banco de dados utilizado nesse projeto:

Modelo do banco de dados

                Passamos agora para a construção do Windows Service. Começamos alterando a estrutura do serviço para facilitar o seu debug. Realizadas as alterações passamos para a construção das funcionalidades do serviço. O primeiro passo é recuperar do banco de dados as configurações para o servidor onde o Windows Service está em execução conforme demonstrado abaixo:

Consultando as configuracoes dos servicos

                Em seguida adicionamos o código para criar os serviços onde utilizamos um dicionário para criar somente uma instância de cada serviço no servidor. Adicionamos nessa instância do serviço todos os endpoints configurados para a cópia desse serviço que rodará no servidor. O código utiliza Reflection dinamicamente carregar o Assembly que contém o serviço e obter o tipo desse serviço:

Criando o servico dinamicamente

                O passo seguinte é a criação e configuração dinâmica dos endpoints. Primeiro criamos através de Reflection uma instância do binding configurado e em seguida obtemos o tipo do contrato também por Reflection. Com essas informações podemos criar o endpoint e adicioná-lo ao serviço:

Criando os endpoints dinamicamente

                O penúltimo passo é configurar a exposição dos Meta Dados. Para expor essas informações devemos criar e configurar uma instância do tipo ServiceMetadataBehavior. Após a configuração adicionamos a instância à lista de Behaviors do serviço. Na classe ServiceMetadataBehavior a propriedade HttpGetEnabled controla a exposição dos Meta Dados e a propriedade HttpGetUrl é utilizada para configurar o endereço onde os Meta Dados serão expostos.

Configurando a exposicao dos Meta Dados

                O último passo é abrir o serviço e verificar seu funcionamento. Para verificar o funcionamento devemos executar a aplicação para carregar os serviços. Podemos conferir o seu funcionamento acessando a WSDL dos serviços hospedados com o uso do internet Explorer:

Abrindo os servicos hospedados

Testando a aplicacao

                Nesse ponto temos nosso serviço pronto para hospedar aplicações WCF dinamicamente. Ao demonstrar a construção desse código passamos por alguns pontos interessantes sobre o uso de Reflection, além de demonstrar como podemos configurar dinamicamente nossos serviços WCF dispensando o uso do arquivo Appconfig. Como sempre deixei uma cópia da aplicação desenvolvida no meu Sky Drive, com o nome ConfiguracaoWCF.

                Deixo como sugestão para os leitores desse post os seguintes pontos: Pode ser desenvolvida uma interface para a configuração dos serviços que manipula a base de dados. Um segundo ponto é a verificação dinâmica de alterações no base de dados, já que nessa versão o Windows Service precisa ser reiniciado para assumir as novas configurações. O terceiro ponto é a possibilidade de extender a aplicação para contemplar as configurações de segurança do WCF.

Abraço a todos e até o próximo post.

Cenários WCF: Regras de negócio na Nuvem

Olá a todos,

                Continuando com a seqüência de cenários para uso de WCF falaremos nesse post sobre como hospedar uma aplicação WCF no Windows Azure. Primeiro devemos lembrar que a plataforma Azure ainda não esta disponível comercialmente, pelo menos até o final desse ano. Após seu lançamento comercial poderemos utilizar esse cenário para hospedar nossos serviços e torná-los altamente escaláveis e independentes da infra-estrutura da nossa empresa. Nessa situação poderemos vender como serviço nossas regras de negócio e o armazenamento das informações que eles utilizam através de uma plataforma altamente escalável, disponível, redundante e com todas as demais características da plataforma Azure, onde pagaremos somente pela quantidade de informação que utilizarmos. Por uma lado teremos menos controle sobre a infra-estrutura, mas por outro teremos nossas aplicações numa infra-estrutura de custo variável onde poderemos comprar recursos de armazenamento e processamento de acordo com a necessidade o que facilitará a previsão de custos e precificação de nossas aplicações.

                Nesse post demonstraremos como hospedar nossos serviço WCF em Web Roles do Windows Azure, porém ainda não disponibilizaremos nossos serviços através do Internet Service Bus pois esse tópico será assunto de outro post. Iniciaremos nosso projeto a partir do template do tipo Cloud Service, onde adicionaremos duas Web Roles: uma (WebRoleCliente) será a aplicação que consumirá o serviço e a outra (WebRoleHost) hospedará nosso projeto WFC.

Criando o projeto do tipo Cloud Service

Adicionando as Web Roles

                Com o nosso projeto criado vamos adicionar o projeto WCF na Web Role que o hospedará. Para isso selecione a WebRoleHost e adicione um item do tipo WCF Service ou do tipo Silverlight-enabled WCF Service. Adicionei um projeto do tipo Silverlight-enabled WCF Service, pois num post futuro utilizarei esse projeto para demonstrar como consumir o serviço WCF em uma aplicação desenvolvida em Silverlight.

Adicionando o projeto WCF na solucao

                Adicionado o projeto WCF nos é aberta a janela com seu código inicial. Como o objetivo desse post é demonstrar como hospedar um serviço WCF no Windows Azure faremos apenas uma pequena alteração em seu contrato/implementação. Com isso temos nossa primeira aplicação WCF hospedada no Windows Azure. Vamos agora gerar o Proxy na outra web role para testar nosso serviço.

Codigo alterado do servico WCF

                No projeto da Web Role chamado WebRoleCliente vamos adicionar uma referencia para o projeto WCF que acabamos de criar. Para isso clique com o botão da direita sobre o projeto da Web Role e selecione “Add Service Reference”. Será aberta uma tela semelhante a imagem abaixo.

Adicionando a referencia do servico

                Em seguida devemos clicar no botão “Discover”. Serão localizados todos os serviços WCF que estão hospedadas em Web Roles. Selecione nossa aplicação WCF e informe um nome para a referência, que será o nome da classe Proxy. Para gerar a classe Proxy clique no botão OK.

Criando a classe proxy para consumir o servico

                Antes de utilizarmos nosso serviço devemos alterar no arquivo web.config da Web Role cliente a porta onde a aplicação WCF será disponibilizada. Podemos obter a porta correta no arquivo ServiceDefinition.csdef do projeto principal:

Obtendo a porta onde estara disponivel o servico WCF

Alteracao no arquivo de configuracao do Web Role que hospeda a aplicacao cliente

                Para a página ASP da Web Role cliente consumir o serviço para testá-lo vamos alterá-la adicionando um label em seu código HTML. Em seguida adicionamos o trecho de código abaixo no evento Page_load para consumir o serviço e exibir o seu retorno no label adicionado:

Codigo utilizado para consumir o servico WCF

                Nesse ponto temos uma aplicação WCF hospedada numa Web Role do Windows Azure que é consumida por outra Web Role do mesmo projeto. Porém nada impede que outras aplicações Web ou mesmo desktop consumam essa aplicação WCF hospedado no Windows Azure. Como podemos ver nesse post a hospedagem de serviços WCF no Windows Azure é uma tarefa bem simples e através dessa plataforma conseguimos disponibilizar nossas aplicações de forma escalável e altamente disponível. Como sempre deixei uma cópia do código utilizado para escrever o post no meu Sky Drive.

Abraço a todos e até o próximo post. 

Cenários WCF: Ambiente desconectado

Olá a todos,

                Continuando com nossa seqüência de cenários para uso de WCF vamos falar nesse post como construir aplicações desconectadas. Nesse modelo de arquitetura a aplicação cliente consegue operar sem a conexão com o servidor central, armazenando os dados processados localmente e sincronizando esses dados com o servidor central em determinados períodos. Por um lado temos a vantagem de não depender de conexão com servidores, mas em contrapartida devemos elaborar um mecanismo de armazenamento de informações e de sincronismo, onde esse último é o grande desafio desse tipo de aplicação.

                Esse modelo deve ser utilizado quando podemos trabalhar com dados desatualizados por algum período. Os cenários recomendados para essa arquitetura são onde a conexão ou mesmo os servidores são instáveis ou não confiáveis e o negócio é altamente impactado por paradas inesperadas do sistema. Esse modelo também nos traz o beneficio de aumentar a janela de manutenção nos servidores centrais, já que a aplicação cliente consegue trabalhar autônoma por algum período, além de economizar em link pois ele pode ser menos confiável e de menor banda.

                O contexto desse post então será uma aplicação desconectada onde utilizaremos o WCF com o uso do MSMQ para realizar o sincronismo entre as aplicações cliente e o servidor central. A grande vantagem no uso dessa combinação é que o MSMQ garante a entrega dos dados, podendo utilizar controle transacional, na ordem de envio além de disparar a aplicação WCF que recebe o conteúdo da mensagem sem a necessidade de desenvolvimento de código. Com isso temos um mecanismo de integração pronto liberando os desenvolvedores para atuarem nas regras e características especificas da aplicação que gerem valor para o negócio. Abaixo temos o desenho da arquitetura de nossa pequena aplicação:

Arquitetura de sistema desconctado

                Para montarmos essa arquitetura temos dois tipos principais de bindings disponíveis: o msmqIntegration e o netMsmq. O binding msmqIntegration já foi demonstrado em outro post, onde o foco era disponibilizar um exemplo de processo assíncrono com o uso de um gerenciador de fila. Esse binding deve ser utilizado quando temos que prover a integração entre aplicações WCF e sistemas legados ou que postem mensagem no MSMQ sem o uso do WCF. Nesse exemplo utilizaremos o binding netMsmq,  que deve ser utilizado quando temos nas duas pontas, a que envia e a que recebe a mensagem, o uso do WCF. Esse binding tem a vantagem de trafegar o objeto ao invés de um texto ou array de bytes reduzindo o tempo de desenvolvimento e possibilidade de bugs, já que não é necessário a montagem de um XML ou array, de um parser e de código para transformar o bloco recebido nas informações necessárias.

                Para começar o desenvolvimento vamos criar uma solução no Visual Studio e adicionar um projeto do tipo Windows Service, que servirá de host para a aplicação WCF, um projeto do tipo WCF Service Library, que conterá as regras para a integração dos dados, e um projeto do tipo WPF Application que fará o papel da aplicação cliente. Primeiro alteraremos o Windows Service para hospedar o projeto WCF, conforme descrito em outro post de cenários para WCF. Realizadas essas alterações passamos para a construção do serviço WCF, que fará a integração dos dados.

                O primeiro passo na construção do serviço que fará a integração dos dados é estabelecer o seu contrato. Para isso devemos trocar o código inicial do template pela declaração do método que receberá a mensagem do MSMQ. É importante notar que devemos decorar o método com o atributo OperationContract informando o valor da propriedade IsOneWay como true. Esse ajuste informará ao WCF que a aplicação que consome esse método, no nosso caso o MSMQ, não espera receber o parâmetro de retorno do método. Outros dois pontos a serem notados na assinatura do método é que ele deve retornar sempre void já que não há necessidade do envio do parâmetro de retorno do método e a declaração do tipo de objeto que esse método recebe.

Contrato do servico

                O objeto que esse método recebe como parâmetro, que deve ser o único parâmetro desse método, é o conteúdo da mensagem que trafegará pelo MSMQ e que foi enviado pelo cliente. Esse conteúdo é definido no contrato do serviço pela classe que foi decorada com o atributo DataContract.

                Definido o contrato devemos escrever o serviço. Como o nosso foco é explicar o funcionamento de uma solução nesse modelo de arquitetura nosso método gravará o conteúdo da mensagem em um arquivo texto, porém podemos desenvolver nesse método regras de negócio utilizando transações com banco de dados e com todos os demais recursos presentes na plataforma .Net. Note que o método que receberá o conteúdo da mensagem foi decorado com o atributo OperationBehavior com os valores dos parâmetros TransactionScopeRequired e TransactionAutoComplete ajustado como true. O parâmetro TransactionScopeRequired é utilizado para iniciar uma transação com o MSMQ quando a mensagem é entregue para o serviço WCF. Desse modo quando o MSMQ entrega a mensagem para o serviço é aberta uma nova transação no gerenciador de fila e a chamada do método é incluída nesse contexto. Caso ocorra uma exceção não tratada no método a mensagem volta automaticamente para a fila. O parâmetro TransactionAutoComplete informa que caso não ocorra uma exceção não tratada a transação será automaticamente confirmada. Esses recursos de transação devem ser utilizados em conjunto com filas transacionais no MSMQ.

Codigo do servico

                Nesse ponto temos o código do nosso serviço WCF pronto. Agora precisamos escrever código para criar a fila e ligá-la ao método do nosso serviço. Para isso devemos voltar ao projeto do tipo Windows Service e alterar o método OnStart para realizar essas operações. Para criar a fila podemos utilizar a interface do MSMQ como descrito em um post anterior ou criar no código da nossa aplicação. Nesse exemplo vamos criar a fila através de código que será escrito no Windows Service, portanto devemos adicionar uma referência a DLL System.Messaging nesse projeto. Em seguida adicionamos o seguinte trecho de código abaixo no método OnStart. Note que passamos o segundo parâmetro do método Create como true, para que a fila seja transacional.

Codigo para criar a fila

                Em seguida alteraremos o restante do método da subida do serviço, pois agora o endereço do serviço deixa de ser uma URI que aponta para um endereço HTTP e passa a apontar para uma fila. Note a formação do endereço da fila: Em primeiro lugar aparece o protocolo utilizado (net.msmq) seguido pelo nome da máquina destinatária da mensagem. Após o nome da máquina é informado o tipo de fila, se pública ou privada, para finalmente informarmos o nome da fila.

Codigo para iniciar o servico

Vamos agora finalizar o lado do servidor configurando os demais parâmetros do serviço através do arquivo app.config. Nesse arquivo temos as configurações comuns a todo serviço WCF, como o nó service seguido dos endpoints. A única alteração significativa é segurança, que nesse exemplo desabilitei para tornar possível a execução em uma máquina stand alone.

Arquivo de configuracao do servico

                Passaremos agora para a construção do lado cliente que será a aplicação WPF criada no começo do post. Voltando nesse projeto devemos adicionar a referência do serviço WCF, atividade que podemos realizar clicando com o botão da direita sobre o projeto e selecionando a opção “Add Service Reference”. Será aberta uma janela onde poderemos localizar o serviço. Para localizar o serviço e gerar o Proxy clique na seta que aponta para baixo no botão Discover e selecione a opção “Services in Solution”. Serão apresentados todos os serviços disponíveis na solução. Selecione o serviço criado, informe um nome de namespace adequado e clique no botão OK.

Adicionando a referencia do servico no cliente

Agora basta alterarmos o código da aplicação WPF para enviar a mensagem. Para isso adicione um botão na tela e adicione o seguinte código no evento click desse botão:

Codigo para enviar a mensagem para o servico

              Podemos então executar a solução e vermos nossas informações chegarem no serviço WCF. Para testar o envio assíncrono das mensagens podemos interromper a execução do Windows Service e vermos nossas mensagens acumularem no MSMQ. Ao executarmos novamente o serviço nossas mensagens serão processadas, configurando o ambiente desconectado.

               Espero que esse post seja útil aos leitores. Como sempre deixei uma cópia da solução utilizada no post no meu Sky Drive, com o nome AmbienteDesconectado.zip. O exemplo que utiliza o binding msmqIntegration possui o nome ProcessoAssincrono.zip.

Abraço a todos e até o próximo post.

SQL Azure: Migrando os dados do servidor local para a nuvem

Olá todos,

    Algum tempo atrás falamos sobre o lançamento do SQL Azure e demos uma visão geral de como utilizá-lo. Durante esse tempo realizei alguns testes com ele e o resultado foi interessante. Em primeiro lugar a migração dos scripts foi tranqüila, o que fiz seguindo as instruções do último trainning kit do Windows Azure. É um pouco trabalhosa a adaptação pois a partir do script gerado pelo SQL Server alguns comandos e palavras chaves devem ser retirados ou substituídos.

    Realizada a migração bastou alterar a string de conexão e a aplicação utilizou normalmente o SQL Azure, sem qualquer alteração em código. Fiz esse mesmo teste utilizando o ADO .NET, LINQ To Entities e o LINQ to SQL. A ressalva fica no LINQ to SQL, pois não foi possível realizar o mapeamento do banco e das stored procedures direto pelo SQL Azure. Portanto tive que construir o contexto de dados utilizando o SQL Server para então alterar a connection string para utilizar o SQL Azure. Outro ponto, porém já esperado, é que o tempo de execução dos comandos para a aplicação é mais lenta pois estamos utilizando um servidor na web e não mais local, ou seja, há um aumento na latência da rede.

    Um ponto não coberto nos meus testes e que segundo a documentação do produto não irá funcionar é o acesso a dois ou mais bancos de dados a partir de uma conexão. Isso porque no SQL Azure não conseguimos alterar o banco de dados em uso após a conexão. Logo se sua aplicação executa comandos que envolvam mais de um banco de dados a sua migração deverá envolver a alterações na sua estrutura de dados.

    Convido a todos que estão testando o SQL Azure a deixarem seus comentários com os pontos fortes e fracos desse novo banco de dados.

 

Abraço a todos.

Cenários WCF: Expondo regras de negócio através de serviços

Olá a todos,

                Conforme nosso último post vamos começar a descrição de cenários de uso para WCF. Os principais conceitos do WCF foram explicados nesse último post, portanto passaremos direto ao cenário e a construção do serviço. Nosso contexto será uma pequena aplicação para agendamento de salas, composta de uma interface web, de um serviço WCF que contém as regras de negócio e um banco de dados para armazenar as informações. Para facilitar o desenvolvimento hospedaremos nosso serviço WCF em um Windows Service, porém nada impede de hospedarmos nossas aplicações WCF no IIS ou no WAS, esse último disponível somente no Windows 2008 server.

                Vamos começar criando o projeto da aplicação WCF utilizando o template WCF Service Library e em seguida adicionamos mais dois projetos: Um projeto do tipo Windows Service para hospedar a aplicação WCF e um projeto do tipo ASP .Net Web Application que será nossa interface com o usuário e consumirá a aplicação. Lembro que nada impede de consumirmos nossos serviços WCF a partir de aplicações desktop, como as desenvolvidas em Windows Forms ou WPF.

Template para desenvolvimento de servicos WCF

 

               O template do projeto WCF contém três arquivos iniciais. O primeiro arquivo com o nome app.config contém as configurações da aplicação e nele podemos parametrizar nosso serviço, ou seja, podemos definir nossos endpoints. Essa parametrização também pode ser definida programaticamente e será foco de outro post. O segundo arquivo chamado IService1 contém o contrato do serviço e um exemplo de uma classe que pode ser utilizada como parâmetro para os métodos do serviço. O terceiro arquivo, chamado Service1, contém a implementação do contrato, ou seja, é o código que implementa as funcionalidades do serviço.

                Note que o contrato é uma interface com escopo público decorada com o atributo ServiceContract, esse atributo informa ao WCF que essa interface é um contrato de um serviço. Os métodos dessa interface que serão expostos como métodos do serviço deverão ser decorados com o atributo OperationContract. No WCF podemos utilizar tipos complexos de dados para passagem de parâmetros através do uso de classes decoradas com o atributo DataContract, que incluí a descrição dessa classe na WSDL. Podemos também controlar quais propriedades dessa classe serão visíveis para o cliente através do atributo DataMember que é adicionado as propriedades que devem ser visíveis. 

Definicao inicial do contrato WCF

                As regras de negócio são construídas na classe que implementa o contrato. Logo nessa classe teremos todos os métodos declarados na interface, lembrando que os métodos visíveis aos consumidores do serviço serão somente os decorados com o atributo OperationContract. Nada nos impede de termos outros métodos públicos ou privados e outras propriedades nessa classe, porém eles não serão visíveis para as aplicações cliente.

Implementacao inicial do servico

               Após construir a classe que será o corpo do serviço podemos compilar o projeto. O resultado da compilação será um arquivo do tipo DLL que podemos hospedar no WAS, no IIS ou em um projeto que gere um executável. Nesse exemplo utilizaremos a última opção, hospedando nosso serviço em um Windows Service.

               Passamos agora para o código necessário para hospedar nossa aplicação WCF. Utilizaremos o projeto do tipo Windows Service que adicionamos no início. O primeiro passo é realizar as alterações nesse projeto para podermos depurá-lo, conforme descrito em um post anterior sobre Windows Service. 

Modificacao para depurar Windows Service

                 O próximo passo é desenvolver os métodos OnStart e OnStop para iniciar e encerrar nossa aplicação. No método OnStart devemos criar uma instância do tipo ServiceHost, que é a classe que realmente hospeda nosso serviço. Através desse objetos conseguimos iniciar ou encerra nosso serviço além de parametrizá-lo dizendo quais serão os seus endpoints. Para criarmos um objeto do tipo ServiceHost é necessário informarmos o tipo da classe do nosso serviço e qual será sua URI. Para encerrarmos o serviço basta chamar o método Close da classe ServiceHost. Como nesse exemplo o objeto que hospeda nosso serviço é chamado em mais de um método da classe ele terá o escopo da classe.

Codigo para iniciar e encerrar o servico WCF

                O passo final na construção do Windows Service é a configuração dos endpoints da nossa aplicação WCF, que nesse caso será realizada através do arquivo app.config. Portanto devemos incluir esse arquivo no projeto da aplicação Windows Service.

              Informamos qual o serviço que estamos configurando através do atributo name do nó service. O valor desse atributo deve ser o fullname da classe que implementa o serviço, que é o nome completo do namespace seguido do nome da classe. Nesse nó de configuração do serviço podemos parametrizar também se disponibilizaremos ou não os metadados do serviço através de requisição http. Essa configuração é realizada através do atributo behaviorConfiguration e do nó serviceBehavior.

              Os endpoints devem ser configurados dentro do nó service onde devemos informar pelo menos o nome do contrato, que é o fullname da interface, e o tipo de binding utilizado. No nosso exemplo utilizaremos o binding HTTP para publicar nossas regras através da porta 80, tornando nossa aplicação acessível a clientes em outras redes. Configuramos o endpoint mex para permitir que o cliente tenha acesso aos metadados do serviço (a WSDL). Para omitirmos os metadados basta excluirmos o nó com a configuração do endpoint que utiliza o binding do tipo mex.

Arquivo de configuracao do servico

              Podemos agora iniciar o Windows Service no modo debug e ver nosso serviço ficar online. Confirmamos a inicialização da aplicação WCF acessando o seu endereço no Internet Explorer. Ao acessar o endereço do serviço deverá aparecer uma tela com uma descrição de como elaborar um trecho de um programa cliente. Pelo Internet Explorer podemos acessar também a WSDL desse serviço.

Confirmando que o servico WCF esta no ar

Obtendo a WSDL do servico

                Nesse ponto temos uma aplicação WCF que podemos executar e depurar, porém ela possui apenas o inicial código do template WCF. Agora alteraremos o contrato e sua implementação para construirmos nossas regras de negócio.

              Nosso serviço terá três métodos: Um método para inclusão de agendamento, outro para alteração de agendamentos existentes e o terceiro método para listar os agendamentos de um dia. Portanto deveremos alterar o contrato do nosso serviço trocando o código inicial pela declaração desses novos métodos. Devemos trocar também o tipo complexo original por um novo tipo que representa o agendamento. Resta alterar a classe que implementa o contrato para implementar os novos três métodos. Lembro que o foco desse post é o serviço WCF, portanto não explicarei o código das regras de negócio, mas colocarei o exemplo completo no meu Sky Drive para que os leitores tenham um exemplo de uma aplicação WCF.

Implementacao do contrato

Implementacao do servico

              Nesse ponto encerramos a construção do nosso serviço porém precisamos de uma aplicação cliente para testá-lo ou consumi-lo. A construção da comunicação entre o cliente e a aplicação WCF é facilitada pelo uso de uma ferramenta de linha de comando que gera uma classe Proxy. Essa classe Proxy expõe todos os objetos e métodos disponíveis no contrato e realiza todo o procedimento necessário para consumir o serviço, como conectar no serviço, enviar e receber as mensagens, etc.

              Para gerar a classe Proxy precisamos do nosso serviço no ar, portanto devemos iniciar a aplicação do tipo Windows Service para que ela hospede e inicie o serviço WCF. Com o serviço WCF no ar devemos iniciar um prompt de comando. Recomendo iniciar o prompt de comando a partir do item de menu que é criado junto com o Visual Studio, que possui o título Visual Studio 2008 Command Prompt, pois ele já possui o caminho do .Net Framework no path. Nessa janela do prompt de comando utilizáramos a ferramenta svcutil para gerar a classe Proxy. Essa ferramenta recebe um parâmetro que é o endereço onde está nosso serviço:

Comando para gerar a classe Proxy

               A classe que foi gerada e informada pela ferramenta é a classe Proxy. Foi gerado também o arquivo output.config que contém todas as configurações para uma aplicação consumir o nosso serviço com o uso da classe Proxy. Essas configurações poderiam ser realizadas programaticamente (no código da aplicação.

               Devemos então adicionar o arquivo com a classe Proxy no projeto que consumirá o serviço, no nosso caso o projeto web, e o conteúdo do arquivo output.config no arquivo de configuração desse projeto. A classe Proxy faz referência a algumas DLLs que ainda não estão referenciadas no projeto portanto devemos adicioná-las. Essas DLLs são: System.Runtime.Serialization e System.ServiceModel.

                Para consumir o serviço devemos criar uma instância da classe Proxy e chamar o método que desejamos consumir. Recomendo utilizar o método Abort quando ocorrer algo inesperado no cliente, pois o serviço é executado em outro processo e não é notificado automaticamente quando algo errado acontece no processo cliente.

Codigo para consumir o servico

               Temos assim uma aplicação WCF rodando em um Windows Service e sendo consumida por uma aplicação web. Nos próximos posts entraremos em outros cenários de uso do WCF. Como sempre deixo uma cópia da aplicação, com o nome AgendamentoSala, no um Sky Drive.

Abraço a todos e até o próximo post.

Distribuindo regras do negócio com WCF

Olá a todos novamente,

                Nesse post vamos falar sobre WCF. O significado de WCF é Windows Comunication Foundation, ou seja, é o Framework base para o desenvolvimento da comunicação entre as aplicações ou parte delas. Com o uso dessa tecnologia podemos desenvolver as interfaces do nosso sistema e através de parametrização definir qual será o protocolo e endereço utilizado. Além disso, temos no WCF a possibilidade de reuso da mesma interface em diversos endereços e que podem utilizar protocolos de comunicação distintos para cada endereço, tudo estabelecido através de parâmetros. Como podemos ver o ponto forte dessa tecnologia é a simplificação e redução do código de nossas aplicações, liberando o tempo que seria necessário para escrevermos a camada de comunicação para concentrarmos nas regras de negócio.

                Uma característica importante do WCF é que ele utiliza o conceito de endpoint, permitindo a interoperabilidade de nossos sistemas com sistemas desenvolvidos em outras tecnologias e plataformas que também suportem esse conceito. O endpoint é composto da união de outros três conceitos conhecidos que são: Address, Binding e Contract. O address é o endereço onde nossa aplicação disponibilizará as funcionalidades. O binding é o modo como a comunicação é realizada, ou seja, o protocolo. O contract é a interface, ou conjunto de funcionalidades, que a aplicação disponibiliza em um endereço (address) e que pode ser consumida através de um protocolo (binding). Vale lembrar que o endpoint não é um conceito da Microsoft, mas sim do W3C.

                Os serviços WCF (WCF Service), como são conhecidas as aplicações que utilizam essa tecnologia podem ser utilizados para construção de aplicações em SOA (Arquitetura Orientada a Serviços), porém o simples uso do WCF não quer dizer que nossa aplicação esteja construída nessa arquitetura. SOA é um modelo de arquitetura que utiliza serviços como sua unidade básica, porém há outros conceitos envolvidos, como o Service BUS e o repositório de serviços, fundamentais para a governança das aplicações, que é uma das vantagens e ponto forte dessa arquitetura.

                Antes de começarmos a escrever os serviços WCF devemos tomar alguns cuidados. Como já discutimos em outro post, a idéia por trás de serviços é que cada serviço realize um conjunto de tarefas relacionadas e somente ele realize essas tarefas, logo é muito importante estabelecer a abordagem de serviços. Essa abordagem guiará os analistas e desenvolvedores a estabelecerem quais funcionalidades devem pertencer a qual serviço. Esse é um passo muito importante, pois uma abordagem errada pode causar a explosão no número de serviços, inviabilizando sua administração e manutenção, ou a concentração de funcionalidades em poucos serviços que aumenta a complexidade das aplicações e o risco de impacto em funcionalidades aparentemente sem relação.

                Outra idéia por trás dos serviços, derivada da primeira, é que uma aplicação (do ponto de vista do usuário) seja composta de diversos serviços, ou seja, uma camada de apresentação pode consumir mais de um serviço para montar sua funcionalidade. Por isso é importante estabelecer também o modelo de integração dos serviços.

                Durante a construção de aplicações WCF, como em qualquer outra aplicação, há três etapas principais: o desenvolvimento, testes e produção. No caso de serviços WCF devemos decidir onde hospedaremos essas aplicações, pois essa decisão impactará diretamente cada etapa. Temo três opções para hospedar nossos serviços: Self-host, onde a aplicação WCF é hospedada em uma console application ou windows service, no IIS e no WAST. Para o ambiente de produção e de teste podemos utilizar um artigo do MSDN e outro artigo do Devx como guias. Porém para o desenvolvimento recomendo hospedar os serviços em console application ou windows services pois podemos iniciá-los no próprio Visual Studio depurar toda a aplicação facilmente reduzindo o tempo de desenvolvimento.

                Outro ponto importante é a relação entre serviços WCF e componentes COM+. Ambos podem ser utilizados para construir e distribuir nossa regras de negócio pelo nosso ambiente, porém há pelo menos duas grandes diferenças. A primeira é que os componentes COM+ utilizam o protocolo RPC, ou seja, seu modelo de comunicação é proprietário do Windows e a interoperabilidade não é possível com outras plataformas. Já os serviços WCF utilizam protocolos suportados em outras plataformas, tornando possível a interoperabilidade.

 A segunda é o grau de granularidade, pois enquanto os componentes COM+ são muitos, onde cada componente implementa poucas regras, os serviços devem ser aplicações maiores, que implementam as regras relacionadas a determinada atividade, logo serão em menor quantidade que os componentes. Lembro que nada impede um serviço WCF de consumir ou ser composto de componentes COM+ ou um componente COM+ consumir um serviço WCF.

                Esses são os principais pontos que devemos pensar antes de começar a construção dos nossos serviços em WCF, nos próximos posts pretendo colocar cenários de uso de serviços WCF com exemplos para esses cenários.

Até o próximo post!

SQL Azure no Ar

Olá a todos,

                Na semana passada tivemos o anúncio do CTP de agosto do SQL Azure, que é a evolução do SQL Data Services onde sua principal mudança é o suporte a comandos T-SQL. Para utilizar a versão desse CTP precisamos de um invitation code, semelhante ao obtido para iniciar o uso do Windows Azure. Esse invitation code pode ser obtido nesse link ou na sessão desse produto no MSDN. Solicitado o código devemos aguardar seu envio por email, que no meu caso demorou uma semana.

                Após receber o código de acesso devemos acessar o portal de administração para criar o nosso projeto que é equivalente a uma instância do SQL Server. A primeira página exibida após o login solicita o invitation code.

Informando o invitation code

Enviado o código somos direcionados para uma página onde informaremos o usuário administrador do projeto e sua senha. Essa senha e de qualquer outro usuário do SQL Azure deve seguir o padrão de segurança, onde são necessários no mínimo dois caracteres numéricos e um caractere do tipo símbolo (que não seja número ou letra):

Criando a "instancia" do SQL Azure

Com o nosso projeto também é criado o banco de dados master, que possui a mesma função do banco master do SQL Server. Através do banco master poderemos criar os demais bancos de dados e seus usuários. Os demais bancos de dados podem ser criados pela janela de administração no portal ,que é acessada através do link Manage do projeto onde deseja criar o esse novo banco. Seremos então direcionados para a tela de administração:

Lista dos projetos no SQL Azure

Tela de administracao da ‘instancia” do SQL Azure

Nessa tela podemos reiniciar a senha do usuário administrador do projeto, criar ou remover bancos de dados e obter a string de conexão dos bancos já criados. Para obter a string de conexão de um banco de dados basta selecioná-lo na lista e clicar no botão “Connection Strings” que está abaixo dessa lista. Nos será mostrado uma janela modal com as três connection strings disponíveis. Como podemos ver o SQL Azure suporta conexões através do ADO .NET e de drivers ODBC ou OLE DB, portanto basta alterarmos a string de conexão das nossas aplicações para elas utilizarem o SQL Azure (assumindo que o banco de dados já foi migrado).   

Connection Strings de um banco de dados no SQL Azure

Para criarmos um novo banco de dados através da página de administração devemos clicar no botão “Create Database”, que está abaixo da lista de banco de dados do projeto. Clicando nesse botão é aberta uma janela modal solicitando o nome do banco. Após informar o nome do banco e clicar no botão “Create” o banco será criado.

Criando um novo banco de dados

Novo banco de dados criado

                Temos também nesse mês o lançamento da documentação dessa nova versão do SQL. Nela temos algumas sessões interessantes e de leitura recomendada. As principais delas são as diferenças entre o SQL Server e o SQL Azure, as guidelines e limitações no uso do SQL Azure,  os comandos T-SQL suportados na versão para a nuvem e os exemplos de código para conectar no SQL Azure. A maior diferença entre a versão local e a versão para a nuvem é a administração do banco de dados.  Como a administração da infra-estrutura, tanto dos servidores como do gerenciador de banco de dados, fica a cargo da Microsoft os comandos para desempenhar essas atividades não são suportados no SQL Azure. Outra diferença entre essas versões é que não é possível alterar o banco de dados em uso através do comando USE, ou seja, na conexão com o banco de dados é obrigatório informar o nome da base que queremos utilizar.

                Uma grande diferença entre o SQL Data Services e o SQL Azure é que não existe mais o modelo ACE, como já visto acima nessa nova versão podemos utilizar ODBC, OLE ou ADO .Net para conectar no banco. Podemos utilizar também o Management Studio do SQL Server 2008, que pode ser obtido com o SQL Express para conectar no SQL Azure.

                Para conectarmos no SQL Azure com o uso do Management Studio iniciamos essa aplicação onde é exibida uma janela solicitando os dados para conectar em uma instância do SQL. Nesse CTP não é possível conectar através dessa primeira janela, portanto devemos clicar no botão “Cancel” para ir para a tela principal.

Abrindo o Management Studio 2008

 Na tela principal clique no botão “New Query” para abrir a janela que solicita os dados para conexão. Informe o servidor, usuário e senha, que podem ser obtidos da connection string no portal de administração. Para selecionar o banco de dados que conectaremos clique no botão “Options” e informe o nome do banco no campo Connect to Dabase (lembre que o SQL Azure não suporta o comando USE para alterar o banco de dados atual). Para conectar no banco master deixe a opção <default>. Após informa o banco de dados podemos clicar no botão “Connect”.

Iniciando uma conexao no SQL Azure

 

Informando os dados para conexao com o SQL Azure

Ao conectar no banco de dados aparece uma mensagem de erro, que podemos ignorar e clicar no botão ok. Após isso temos a janela onde podemos criar e executar nossos comandos e queries no banco de dados:

Management Studio conectado no SQL Azure

Segundo a documentação do SQL Azure e o Blog do time do produto essa versão é compatível com o SQL Server 2008 (lembrando das restrições), logo os mesmos scripts utilizados para criar os objetos no SQL Server devem funcionar para o SQL Azure. Farei esses testes nas próximas semanas e colocarei no blog os resultados.

Abraços a todos e até o próximo post.

Explorando as queues do Windows Azure

Olá a todos

                Nesse post falaremos sobre o gerenciador de filas do Windows Azure. Esse serviço possui funcionamento semelhante aos gerenciadores de fila Msmq e IBM MQSeries, que é fornecer uma estrutura para processamento assíncrono. Em outros posts já descrevemos os cenários para uso de filas e as principais características dos gerenciadores de filas além de mostramos um exemplo de uso do msmq no ambiente on premise portanto vamos nos deter ao uso das filas no Windows Azure.

                Até o momento o mecanismo de filas do Windows Azure é mais simples que dos outros produtos já que faltam muitas das funcionalidades presente nos gerenciadores de filas on premise. Entretanto esse mecanismo permite que tanto aplicações na nuvem como locais acessem as mesmas filas permitindo montarmos cenários de comunicação assíncrona entre as plataformas on the cloud e on premise. Assim poderemos ter uma aplicação web na nuvem coletando as informações que serão enfileiradas para posterior processamento/entrada no ambiente local ou vice-versa. Esse mecanismo reduz o tempo de resposta para o usuário porque seus dados são “postados” em uma fila num servidor próximo evitando a latência de rede necessária para acessar outros servidores. Outro ponto é o aumento de disponibilidade da aplicação para o usuário já que a indisponibilidade desses outros servidores que realizam o processamento em background não afetará a experiência do usuário na web o que conseqüentemente permite também maiores janelas de manutenção nos servidores.

Outro cenário interessante é a comunicação entre roles do Windows Azure. Com o uso de filas podemos realizar a comunicação entre web role e worker roles sem afetar o tempo de resposta da aplicação para o usuário. As informações também podem circular por diversas worker roles sendo processadas na seqüência de envio da web role. Embora não tenhamos falado sobre essa característica dos gerenciadores de filas ela é muito importante. Essa característica, de onde vem o nome desses gerenciadores, garante que as mensagens são disponibilizadas para as aplicações na mesma ordem que foram enviadas para o gerenciador. Através dessa funcionalidade podemos eliminar o desenvolvimento de funcionalidades que determinam a ordem de chegada dos dados. Lembro que essa característica funciona para mensagens com a mesma prioridade, pois caso seja enviada ao servidor uma mensagem com prioridade superior às demais ela será processada primeiro.

Para demonstrar o uso de filas no Windows Azure nosso cenário fictício será um pequeno site de leilões. Os itens ofertados serão gravados em tables do Storage Service e listados em uma página ASP .Net que também será a interface para o usuário enviar dos lances. Para permitir diversos lances ao mesmo tempo utilizaremos o gerenciador de filas para receber e registrar os lances além de colocá-los em ordem de chegada para o processamento. A ordem será importante porque o vencedor do leilão será o primeiro usuário que realizar o maior lance. A regra do leilão será aplicada em background por uma worker role.

Já descrevemos em outros posts como iniciar o projeto, o desenvolvimento da camada de apresentação em ASP .NET, o uso das tables e da worker role, portanto focaremos o uso das queues. As queues são parte do Storage Services portanto para utilizá-las devemos criar um projeto do tipo Storage Account no Windows Azure conforme demonstrado em um post anterior. Utilizaremos a biblioteca StorageClient que acompanha o Trainning Kit do Windows Azure, logo nosso primeiro passo será incluir a StorageClient na solução e adicionar o parâmetro com o endereço do endpoint do gerenciador de filas nos arquivo de configuração do projeto principal.

Para utilizar as queues com o StorateClient no ambiente local basta manter os valores dos parâmetros da solução porém para utilizá-las na nuvem teremos que trocar os valores dos parâmetros o AccountName, AccountSharedKey e o QueueStorageEndpoint para os valores do projeto do tipo Storage Account, conforme descrito no post sobre Blobs. O endereço do endpoint das queues será HTTP://queue.core.windows.net, já que a StorageClient se encarrega de colocar o nome da sua solução no endereço.

Arquivos com a definicao dos parametros (.csdef)

Arquivo com os valores dos parametros (.cscfg)

Passamos agora para as alterações para enviar ou receber mensagens para uma fila e para essas tarefas precisamos obter o objeto que representa a fila. Para conseguirmos esse objeto primeiro precisamos de um objeto do tipo StorageAccountInfo que aponte para o endpoint do gerenciador de filas. Esse objeto será utilizado no método Create da classe QueueStorage para autenticar no Storage Service e obter uma referência para o gerenciador de filas. Através dessa referência obtemos um objeto que representa a fila e com ele podemos enviar ou receber as mensagens. Porém antes de utilizá-la devemos verificar se a fila existe e caso contrário criá-la:

Codigo para criar a fila

Após criada a fila podemos utilizá-la para enviar/receber mensagens.  Para enviar uma mensagem precisamos de uma instância da classe Message que recebe em seu construtor um parâmetro que será o seu conteúdo. Esse parâmetro pode ser uma string ou um array de bytes, ou seja, podemos enviar através de uma mensagem um texto ou qualquer objeto que possa ser serializado. A mensagem é enviada para a fila através da chamada do método PutMessage da classe que representa a fila:

Codigo para enviar uma mensagem para a fila

Nesse ponto podemos testar a aplicação em modo debug e verificar o seu funcionamento. Para vermos as mensagens gravadas nas queues podemos utilizar o aplicativo Azure Storage Explorer:

Mensagens enviadas para a fila no Azure Explorer

Recebemos mensagens chamando o método GetMessage do objeto que representa a fila. Esse método retorna a próxima mensagem ou null caso não exista mensagens. Também podemos obter todas as mensagens disponíveis de uma vez através do método GetMessages, ou apenas visualizar a mensagem através do método PeekMessage. Após processar os dados da mensagem devemos retirá-la da fila com o uso do método DeleteMessage:

Codigo para receber mensagens da fila

Agora podemos executar nosso exemplo e cadastrar alguns itens para receberem lances e através da página principal (Default.aspx) conseguimos enviar nossos lances.  Na worker role poderemos verificar a chegada e processamento da mensagem.

 Através desse exemplo demonstramos o uso das queues do Windows Azure. Como já dissemos as mensagens podem ser enviadas ou recebidas por aplicações na nuvem ou locais, funcionando como uma ótima ferramenta de integração entre ambientes. Como sempre deixarei no meu Sky drive a solução utilizada para construir esse exemplo que se chamada SiteLeilao.zip. Também deixarei o aplicativo publicado no Windows Azure no endereço http://406335c565c24f79b4bd87a8bcf388ee.cloudapp.net/ até o próximo post sobre Windows Azure.

Abraço a todos.

Worker Role do Windows Azure

Olá a todos,

                Nesse post vamos falar sobre o projeto do tipo worker role do Windows Azure. Uma worker role tem o comportamento semelhante a um serviço do Windows, logo o cenário de utilização para esse tipo de projeto são processamentos executado em background, ou seja, sem a necessidade de iteração direta do usuário. As worker roles são iniciadas após sua inicialização e permanecem ativas por todo o tempo, portanto tão importante quanto a lógica do processamento é a lógica de espera quando não há o que processar para não sobrecarregar o servidor e desperdiçar recursos (lembre-se que na nuvem somos cobrados por processamento). Os cenários de processamento background para serviços já foram apresentados em outro post, logo passarei diretamente para o exemplo.

                Nosso exemplo será uma simulação de uma aplicação de ordem de compras. O usuário utiliza uma interface para enviar sua ordem e verificar as ordens enviadas e seus status. Um processamento assíncrono, sem iteração com o usuário (em brackground), verifica o valor da ordem e toma a decisão para enviar, rejeitar ou reprovar. Como o foco do post é a worker role não detalharei aqui como foi construída a interface web e como utilizar o mecanismo de armazenamento do tipo table. Esses assuntos foram apresentados em detalhes em outros posts.

                Primeiro devemos criar um projeto a partir do template Cloud Service (disponível a partir do CTP de julho) e em seguida adicionar uma web role e uma worker role.

Novo template para aplicacoes na nuvem (CTP julho/2009)

Adicionando roles na solucao

Após criada a solução temos três projetos (ProjetoBackground, WebRole1 e WorkerRole1). Expandindo o projeto WorkerRole1 temos apenas um arquivo (WorkerRole.cs) que contém o template inicial de uma worker role conforme abaixo:

Template inicial de uma worker role

Nesse template temos dois métodos: O método Start é chamado para iniciar a worker role, que ao contrário dos serviços do Windows tem o laço que controla o tempo de vida da aplicação fica nesse método. O método GetHealthStatus é utilizado para informar ao sistema operacional que o serviço está no ar. Podemos alterar o método Start para iniciar uma thread e sobre-escrever o método Stop (não presente no template inicial) para encerarmos a thread na parada da worker role, semelhante ao post que demonstra a construção de um serviço do windows. Dessa maneira poderemos migrar nossos serviços on premise para a nuvem com muita facilidade.

Template da worker role modificado para iniciar thread

Nesse ponto poderemos ver nossa worker role em ação. Para isso inicie a aplicação local, você verá que foi iniciada a Fabric local (na tray icon, ao lado do relógio)

Fabric iniciada

Através de um duplo clique no ícone da Fabric você pode acessar a interface de usuário desse recurso. Nele podemos enxergar todos projeto e suas roles que estão em execução. Clicando sobre nossa worker role veremos sua janela console onde vemos registrada a mensagem que é enviada toda vez o conteúdo da laço que controla a vida da thread é executado. Vamos agora alterar essa thread para ler os dados de uma table e realizar seu processamento.

Acompanhando o processamento do ambiente local

Para realizar o processamento do exemplo precisamos alterar somente o método que é executado pela nova thread. Inicialmente recuperamos o evento que sinaliza o fim da thread através do parâmetro passado para o método. Em seguida criamos o contexto de dados para realizar a pesquisa e a atualização dos registros:

Criando o contexto de dados

E  dentro do laço que controla o tempo de vida da thread faremos a pesquisa, seguida da regra de aprovação (lembre-se que é apenas uma simulação) para então atualizarmos os registros no Storage:

Codigo com a funcionalidade do servico

Assim o código completo do método executado pela thread fica conforme abaixo:

Codigo completo da thread de processamento

Vamos agora para uma rápida passagem sobre a aplicação web para explicara seu funcionamento. A interface possui os controles para o usuário informar a descrição, o valor e um botão para enviar a ordem. Essa página possui também uma grid para exibir as ordens enviadas e seus status.

Interface com o usuario para entrada e visualizacao das ordens

Ao cadastrarmos uma nova ordem ela será enviada com o status de pendente (P). Após alguns instantes clicamos no botão atualizar onde poderemos ver o novo status da ordem, que foi alterado por nossa worker role.

Como sempre deixei uma cópia do código fonte utilizado nesse post no meu Sky drive e até o próximo post sobre Windows Azure deixarei esse exemplo publicado e disponível para visualização no endereço http://3a602ce80d084942a9b455f9133938ee.cloudapp.net/Default.aspx.

Abraço a todos e até o próximo post.