App Engine: Construindo o lado Server com o auxílio do GWT

Olá a todos

                Nesse post demonstraremos como podemos construir a comunicação entre os lados cliente e servidor utilizando o GWT. Como já dissemos em um post anterior essa comunicação possui a desvantagem de utilizar um protocolo proprietário, portanto não será possível a integração desse modelo com outras tecnologias. Em contrapartida sua implementação é muito simples. Começaremos o nosso exemplo utilizando o projeto construído no post anterior sobre o assunto. A partir desse ponto desenvolveremos o código da funcionalidade do lado Server e a comunicação entre as camadas.

                Antes de iniciarmos o desenvolvimento de código vamos entender como funciona o mecanismo de comunicação do GWT. Os métodos que serão expostos no lado Server para serem invocados pelo cliente deverão ser listados em uma interface. O serviço deverá então implementar essa interface em uma classe cujo nome será composto pelo nome da interface com o sufixo Impl. Na estrutura do GWT a chamada dos métodos ocorre de forma assíncrona. Portanto teremos no lado cliente um método para invocar o lado Server e um evento que será disparado quando o lado cliente receber a resposta do servidor. Para montarmos a estrutura assíncrona deveremos criar outra interface no lado cliente com os métodos e os eventos. A criação da comunicação entre os dois lados é realizada pelo objeto GWT através do método Create. Esse método criará um objeto que poderemos utilizar para invocar os métodos do lado Server.

Essa estrutura é muito semelhante ao cenário de um serviço WCF consumido por uma aplicação desenvolvida em Silverlight. Em ambas as tecnologias temos uma interface que lista os métodos disponibilizados e as chamadas são assíncronas. A implementação das funcionalidades é realizada através de uma classe que implementa essa interface. O ponto fraco do GWT é que precisamos respeitar um padrão para criar as classes. Já o ponto fraco da plataforma .Net é que precisamos adicionar a referência do serviço, caso contrário o código torna-se mais complexo.

Começaremos a implementação da comunicação entre o lado cliente e o lado servidor estabelecendo a interface que listará os métodos que serão expostos. Essa interface deverá ser criada na subpasta cliente e extender a interface RemoteService. Nesse exemplo adicionaremos uma interface chamada ControleAcesso que possuirá um método chamado Login. Essa interface deverá ser decorada com o atributo RemoteServiceRelativePath, que será utilizado para formar o endereço do servlet.

Criando a interface principal

Criaremos agora o lado servidor. Para isso adicione uma classe na subpasta Server. Essa classe deverá herdar da classe RemoteServiceServet e implementar a interface criada anteriormente. Tome o cuidado para nomear essa classe com o nome da interface seguido do prefixo Impl.

Classe que implementa o servlet

Podemos depurar o lado Server em nossa máquina de trabalho, porém são necessárias algumas configurações no arquivo web.xml. Primeiro precisamos adicionar uma entrada na sessão servlet, onde teremos o nome do servlet, que será o nome da interface, e o nome completo da classe que implementa essa interface. Em seguida devemos adicionar uma entrada na sessão servlet-mapping , onde devemos adicionar novamente o nome da interface e o parâmetro informado no atributo RemoteServiceRelativePath, que está na declaração da interface.

Configurando a aplicacao para depurar o servlet

Desenvolveremos agora o lado cliente da comunicação. O primeiro passo nessa tarefa é definirmos a interface para a chamada assíncrona. O nome dessa interface deverá ser formado pelo nome da interface principal seguido do sufixo Async e deverá ser criada na subpasta cliente. Para cada método da interface principal deveremos criar um método equivalente com o mesmo nome e parâmetro, porém os métodos dessa interface deverão retornar void e possuir como último parâmetro um objeto do tipo AsyncCallBack que recebe como tipo o mesmo tipo de retorno do método da interface principal.

Codigo da interface assincrona

Resta agora realizar a chamada ao método. Voltaremos na classe LoginPanel, desenvolvida no post anterior, e alteraremos o evento de click do botão. O primeiro passo é criar um ponteiro para a interface através do método Create do objeto GWT. Em seguida devemos criar um objeto do tipo AsyncCallBack, recebendo o mesmo tipo de objeto que o retorno do método da interface principal e que implemente os métodos onFailure e onSuccess. O evento onSuccess será disparado quando a chamada do método for completa, já o método onFailure é chamado quando ocorre algo inesperado na execução do método.

Codigo para consumir o servlet

Podemos agora testar o exemplo. Adicione breakpoints no evento do clique do botão e no código Server. Em seguida execute a aplicação e clique no botão para ver seu funcionamento. Como sempre deixei no meu Sky Drive uma cópia do projeto utilizado para construir o exemplo do post, nesse caso o arquivo chama-se GWT_Server.zip.

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

Silverlight: Consumindo serviços hospedados em Windows Services e outros executáveis

Olá a todos,

                Nos últimos posts sobre a plataforma Microsoft demonstramos como aplicações desenvolvidas em Silverlight podem consumir serviços WCF. Nesses posts abordamos como consumir um serviço WCF no mesmo local de origem ou em outros locais de origem, porém nesses exemplos as aplicações WCF eram hospedadas no IIS ou em Web Role do Windows Azure. Nesse post abordaremos o consumo de serviço WCF que estejam hospedados em Windows Services, Console Application ou outros tipo de executáveis.

                Primeiro devemos lembrar que nossas aplicações desenvolvidas em Silverlight ficam hospedadas em páginas web, normalmente HTML ou ASPX. Portanto se tivermos uma aplicação WCF hospedada em algum executável ele necessariamente estará em outro local de origem, pois duas aplicações não conseguem utilizar a mesma porta com a mesma URI. Como conseqüência precisaremos disponibilizar com os serviços o arquivo crossdomain.xml ou o arquivo clientaccesspolicy.xml.

                Entretanto, não basta simplesmente adicionar esses arquivos na mesma pasta onde estão os serviços, pois a nossa aplicação em Silverlight não conseguirá acessá-los. A solução para essa situação é desenvolvermos outro serviço WCF que disponibilize o conteúdo desses arquivos. Porém há uma restrição no desenho deve serviço, pois as aplicações em Silverlight buscam os arquivos de acesso através de uma requisição REST na raiz da URI. Logo esse serviço deverá obrigatoriamente disponibilizar o conteúdo desses arquivos através do protocolo REST via verbo GET na raiz da URI onde está exposto o nosso serviço.

                Para demonstrar a construção dessa estrutura começaremos um novo projeto. Nesse projeto adicionaremos um projeto do tipo Windows Service, que servirá de host dos serviços WCF, e uma aplicação Silverlight, para consumir o serviço principal.

Estrutura inicial da solucao

               No projeto Windows Service adicionaremos um serviço WCF e alteraremos o método fornecido no template para receber e retornar um parâmetro do tipo string. Esse método então funcionará como um eco. Na prática os métodos de nossas aplicações WCF executarão tarefas mais complexas, porém deixamos o exemplo simples para focarmos na disponibilização dos arquivos de acesso.

Contrato do servico principal

Implementacao do servico principal

                Em seguida devemos adicionar outro serviço WCF que publicará o conteúdo dos arquivos de acesso para aplicações em Silverlight, Flash ou JavaScript. Nesse exemplo publicaremos o arquivo clientaccesspolicy.xml, porém podemos seguir os mesmos passos para publicar o arquivo crossdomain.xml. Como as aplicações cliente buscam o conteúdo de acesso na raiz do URI dos serviços que serão consumidos precisamos somente de um serviço expondo esse contudo, logo faz sentido termos um serviço exclusivo para essas tarefa.

                Como o serviço deverá expor o conteúdo através do protocolo REST e pelo verbo GET devemos realizar algumas alterações no contrato. Ele deverá ser decorado com o atributo WebGet e o método deverá retornar um tipo Message do namespace System.ServiceModel.Channels.

Contrato do servico que disponibiliza o arquivo de acesso

                Na implementação do serviço o método deverá ler o conteúdo do arquivo e retorná-lo através de um tipo Message. Nesse ponto há um detalhe importante: se passarmos diretamente o stream para o método que cria o XMLReader ele travará o arquivo aberto com acesso exclusivo, portanto outras execuções desse método ou outras aplicações que tentarem abri-lo receberão uma exceção. O modo de contornar essa situação é carregarmos o conteúdo do arquivo em uma variável do tipo string, passando o conteúdo dessa string para o método que cria o XMLReader. Outro ponto que deve ser lembrado é que não podemos fechar o objeto XmlReader. Pois caso ele seja fechado a aplicação cliente não conseguirá ler o conteúdo do stream que será disponibilizado pelo método.

Implementacao do servico que disponibiliza o conteudo do arquivo de acesso

               Para finalizar nossa estrutura devemos criar o arquivo clientaccesspolicy.xml. Para isso podemos adicionar um novo item do tipo Arquivo XML no projeto que hospeda os serviços WCF. Criado o arquivo na solução devemos alterar a propriedade Copy to Outpu Directory para Copy Always, assim esse arquivo será sempre copiado para a mesma pasta do executável. Caso contrário deveremos alterar a abertura do arquivo na implementação do serviço para busca esse arquivo em outra pasta.

Alterando a propriedade do arquivo ClientAccessPolicy.xml

               Outro detalhe importante nessa implementação é o conteúdo desse arquivo, pois deve estar explicito quais tipos de requisição (HTTP ou HTTPS) serão permitidas. No exemplo permiti o consumo tanto por requisições HTTP como HTTPS.

Conteudo do arquivo ClientAcessPolicy.xml

               Agora devemos alterar o início do Windows Service para ele carregar e abrir os serviços. O serviço principal deverá utilizar o binding BasicHttpBinding, pois esse é o único binding disponível para aplicações desenvolvidas em Siverlight. Já o serviço que disponibiliza o conteúdo do arquivo de acesso deverá utilizar o binding WebHttpBinding e seu endereço deverá ser a raiz da URI do serviço principal.

Configuracoes dos servicos

               Nesse ponto a estrutura do lado Server está montada. Podemos agora gerar o Proxy e consumir o serviço principal. Para gerar o Proxy compilei os projetos como debug e executei o host via linha de comando. Nesse caso lembre-se de iniciar a janela com privilégios de administrador. O código da aplicação em Silverlight para consumir o serviço pode ser montado conforme já descrito em outro post.

Codigo da aplicacao Silverlight para consumir o servico

               Nesse ponto temos concluído também o lado client e portanto podemos testar o nosso exemplo. Para entendermos completamente como uma aplicação desenvolvida em Silverlight consome serviços WCF é interessante adicionarmos break points tanto no início dos eventos do click do botão e da resposta do serviço na aplicação Siverlight, como no início dos métodos dos serviços.

               Como sempre deixei o exemplo utilizado para escrever o post no meu Sky Drive, esse exemplo está com o nome WCF_SelfHosted_Silverlight.zip.

Abraço a todos!

App Engine: Utilizando o GWT para construir a camada de apresentação

Olá a todos,  

                Em posts anteriores fizemos uma pequena apresentação do que é o App Engine e como preparar uma máquina para desenvolver nessa plataforma. Já demonstramos também como é possível desenvolver a camada de apresentação em páginas JSP e como publicar nossa aplicação nos servidores do App Engine. Nesse post continuaremos falando sobre como desenvolver a camada de apresentação nessa plataforma. Porém dessa vez o foco será utilizar o Google Web Toolkit (GWT). 

                O GWT é uma biblioteca que facilita a construção da camada de apresentação e da comunicação com o lado Server das nossas aplicações. Para quem conhece a plataforma Microsoft podemos dizer que o GWT é um meio termo entre o Silverlight e ASP .Net. Suas principais vantagens são a ausência da necessidade da instalação de um plug-in na máquina cliente, pois o código que é recebido pelo browser é HTML e JavaScript, e a facilidade de desenvolvimento (quando comparado com as páginas JSP). Os seus dois pontos fracos são: a falta de uma ferramenta de edição da interface com o usuário, pois tudo é feito no código (caso algum leitor conheça alguma ferramenta nos avise via comentário nesse post) e a comunicação com o lado Server da aplicação, que é realizada por um protocolo proprietário.

                Nesse post demonstraremos como escrever a camada de apresentação de nossas aplicações nessa tecnologia além de apresentar um modelo para facilitar a troca das telas em nossos softwares. Deixaremos a construção da comunicação com o lado Server para outro post. Vamos passar para o nosso exemplo que será um tela de login seguido de uma tela com uma opção para o usuário que acessa outra tela. A partir do desenvolvimento dessa mecânica é esperado que fique fácil a construção da navegação com diversas telas.

                O primeiro passo é criarmos o projeto no Eclipse, através do menu File, opção New e em seguida Web Application Project. Nos será aberta uma tela semelhante a imagem abaixo, onde devemos informar o nome do projeto e de seu pacote. Antes de clicar com o botão OK para criar o projeto verifique se as opções Use Google App Engine e Use Google Web Toolkit estão habilitadas. A opção Use Google App Engine fornece ao projeto as configurações necessárias para ser hospedado nos servidores do Google. Já a opção Use Google Web Toolkit configura automaticamente o projeto para utilizar o GWT.  

Criando um projeto que utilize o GWT

Confirmadas as configurações do projeto será criada uma estrutura semelhante à descrita em um post anterior. Porém será adicionada a referência ao GWT e serão criadas mais duas subpastas dentro da pasta src: uma pasta com o nome do pacote e com o sufixo Server e outra pasta com o sufixo client. Na pasta com o sufixo Server ficam os códigos que rodarão no lado Server e que será assunto de outro post. Na pasta com o sufixo client devemos colocar todos os códigos que são executados no lado cliente.   

Podemos então executar o nosso projeto com o template inicial para confirmar que a instalação de todos os requisitos foi realizada com sucesso. Ao executar o projeto note que duas janelas são abertas. Uma delas é a janela com um mini browser onde é executada a aplicação e outra janela com o nome Google Web Toolkit Hosted Mode é uma aplicação que executa o código Java, transformando o resultado em HTML e JavaScript. Segundo a documentação do GWT em tempo de execução é identificado qual o browser que está em uso pelo cliente e o conteúdo enviado é adaptado para esse browser, evitando a necessidade de customizações ou verificações desse tipo no nosso código. Note que o conteúdo dessa última janela é um log do que ocorre na nossa aplicação, algo semelhante ao que podemos fazer com a Fabric local no Windows Azure. Podemos encerrar a sessão fechando essa janela.  

Tela do host do GWT

Antes de iniciar as alterações no código vamos entender como funciona esse exemplo. A aplicação é iniciada quando a página HTML, situada na pasta war, é acessada. Nessa página temos um código HTML simples onde os pontos de interesse são o código JavaScript, responsável pela chamada ao código Java que será transformado, a chamada desse código javascript e dois itens da tabela que possuem id. Na pratica os únicos pontos que temos que nos preocupar é com esses dois itens da tabela que possuem id, pois como veremos mais adiante são esses itens que conterão o resultado da execução do código Java.  

Codigo original da pagina HTML

  Vamos agora examinar a classe inicial do nosso projeto que pode ser localizada na subpasta com o sufixo client. O arquivo que contém essa classe possui o mesmo nome do projeto. Note que a classe herda de outra classe chamada EntryPoint. A classe EntryPoint possui a implementação necessária para iniciar a execução do código Java pela engine do GWT. O primeiro método chamado que temos controle é o onModuleLoad. Nele temos a criação e customização de diversos tipos de objetos farão a composição da tela. Nesse método temos o código que monta a relação entre os IDs da página HTML e o código Java, que é realizado pelo objeto RootPanel da clase EntryPoint. Esse objeto tem a capacidade de adicionar ou remover os controles de IDs da página HTML. 

Trecho do codigo inicial do template

Entendido o funcionamento básico do template inicial vamos começar as alterações para construir a nossa aplicação removendo todo o código do método onModuleLoad. Alteraremos também a página HTML, trocando o objeto table por um div, pois para essa demonstração será necessário apenas um item que receberá todo o conteúdo da execução do nosso código. Além disso, vamos desenvolver um método padrão para facilitar a troca de telas. Esse método é baseado no tutorial PageSwitch publicado no site do Silverlight. 

Codigo da pagina HTML alterado para o exemplo

O primeiro passo é criar uma interface para facilitar a troca de parâmetros entre as telas, assim bastará que os objetos que representam as telas implementem essa interface para estarem prontos para receberem parâmetros de telas anteriores. Essa interface, assim como o restante do código utilizado nesse post devem ser criados na subpasta com o sufixo client. Nesse exemplo utilizei o nome ISwitchable (mesmo nome utilizado no tutorial de Silverlight). Essa interface estabelece apenas um método que será chamado durante a troca de telas com passagem de parâmetros, recebendo um objeto do tipo object para permitir a passagem de qualquer tipo de objeto entre as telas.  

Codigo da interface para troca de parametros entre paineis

O próximo passo é criar a classe que realmente trocará as páginas. Essa classe deverá herdar da classe Widget do pacote do GWT. Nesse exemplo chamei essa classe de PageSwitcher (mesmo nome utilizado no tutorial de Silverlight). Essa classe possui duas versões do método Navigate, onde ambas farão a troca de páginas. A primeira versão troca as páginas sem passagem de parâmetros. Já na segunda versão do método ele realiza a troca de telas com a passagem de parâmetros. A troca de telas é realizada removendo o painel atual do id do HTML e inserindo um novo painel. Quando ocorre essa ação as telas são trocadas instantaneamente. 

Codigo da classe que realiza a troca dos paineis

  O último passo para a montagem do modelo para troca de telas é criar uma classe que realiza a chamada do método Navigate da classe PageSwitcher. Essa classe visa facilitar o uso dessa estrutura. No exemplo chamei essa classe de Switcher. Essa classe possui uma variável membro do tipo PageSwitcher declarada como static. A declaração como static permite que utilizemos a mesma instância do objeto, evitando criarmos diversas cópias desse tipo na memória. Semelhante ao método Navigate da classe PageSwitcher temos nessa classe duas versões do método Switch. Uma versão para troca de telas sem passagem de parâmetros e outra versão para trocarmos a tela informando parâmetros. 

Codigo da classe Helper que facilita a troca dos paineis

Vamos agora passar para a montagem da interface do usuário e uso da nossa estrutura. Para a montagem de cada tela da nossa aplicação precisamos de um objeto do tipo Panel, ou que o estenda, para armazenar e exibir nossos controles. Nesse exemplo criei três classes que herdam da classe VerticalPanel, uma para a tela de login, uma para a tela principal e outra para uma tela de detalhes.

Nesse ponto é onde temos o ponto fraco da tecnologia, pois como não temos um editor visual para desenhar a tela, temos que fazê-lo no código aumentando o tempo de desenvolvimento. Nas telas principal e de detalhe adicionei em cada um label para identificar a tela e um botão para navegar entre elas. Note que no código temos que criar uma instância de cada objeto, alterar suas propriedades de acordo com nossa necessidade e adicionar no painel para estarem visíveis. Além disso, devemos montar via código também os handlers para os eventos, que nesse caso utilizamos somente o clique do mouse nesses botões. Nos eventos do clique do mouse sobre os botões ficam a chamada da nossa estrutura de troca de telas (na verdade painéis), conforme pode ser visto no código. 

Codigo de um dos paineis com a implementacao do Handler de click do botao que realiza a troca de paineis

Na tela de login montamos uma estrutura um pouco mais complexa, pois adicionamos controles para o usuário informar o login e a senha, além de outros painéis para organizar os controles. Porém nesse post ainda não faremos validações sobre os controles, pois nosso foco agora é apenas demonstrar o uso básico do GWT e uma estrutura para troca de painéis que facilite a construção de aplicações nessa tecnologia. Assim ao clicarmos no botão login seremos direcionados para o painel principal.

Agora podemos executar a nossa aplicação e vê-la funcionando. Temo então um exemplo bem simples, mas que nos permite experimentar o uso do GWT junto com o App Engine. Para publicar essa aplicação nos servidores do Google devem ser seguidos os mesmos passos descritos em um post anterior. Como sempre deixei os fontes utilizados para escrever o post no meu Sky Drive, nesse caso com o nome POCAppengine.zip. Além dos fontes deixei uma cópia do tutorial original de Silverlight explicando o funcionamento do modelo de troca de painéis.

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

Criando e hospedando uma aplicação no App Engine

Olá a todos,

                Nesse post faremos nossa primeira abordagem no App Engine. Como já dito anteriormente o App Engine é a plataforma para Cloud Computing da Google. Nessa plataforma, que já é utilizada pelas aplicações do Google, podemos hospedar nossas aplicações que podem ser construídas em Phyton ou Java. Nesse post demonstraremos como criar uma aplicação simples, executá-la no ambiente de desenvolvimento e enviá-la para a nuvem na plataforma App Engine.

                Começaremos criando nosso projeto utilizando o Eclipse como IDE através do menu File, opção New e em seguida Web Application Project. Após acessada essa opção no menu é aberta a tela para informamos os dados do projeto, como nome, nome do pacote (semelhante ao namespace em .Net) e se utilizaremos alguns dos recursos disponíveis. Nos recursos disponíveis podemos escolher utilizar o Google Web Toolkit (GWT) que é um recurso para construirmos a camada de apresentação e a comunicação com o lado servidor, semelhante aos Prism em Silverlight. Outra opção que podemos escolher é selecionar qual a versão do App Engine que utilizaremos em nossa solução.

Criando o projeto com o Plugin para o Eclipse

Opcoes de um novo projeto

Quando utilizamos o template do Pluging para o Eclipse já é criada uma estrutura de projeto como a mostrada abaixo. Nela temos a pasta war onde ficam os arquivos de configuração da nossa aplicação e a página inicial. Temos também uma estrutura chamada src onde ficam os arquivos com o código-fonte.

Estrutura do projeto

A página índex.html que está na pasta war é a página inicial, porém o arquivo que será a página inicial pode ser alterada no arquivo web.xml. Na página índex.html temos um link que quando clicamos somos redirecionados para o servlet que contém o nosso código. O código que será executado está no arquivo HelloWorldSerlet.java e no momento ele escreve HelloWorld no browser. Poderemos alterar a vontade esse código, porém para a finalidade desse post deixarei como criado pelo Plugin.

Codigo do servlet

O próximo passo é executarmos localmente a aplicação em modo Debug através do menu Run selecionando a opção Debug, ou apertando a tecla F11. 

Iniciando o debug da aplicacao

Note que após um processamento aparecerá uma mensagem na janela Console indicando o endereço da nossa aplicação porém não é aberto nenhum browser. Para ver o funcionamento da aplicação deveremos abrir o browser e acessar o endereço informado na janela Console. Nesse modo poderemos inserir break points e depurar nossa aplicação. Outra característica desse ambiente é que não precisamos reprocessar a aplicação quando alteramos pois as alterações são assumidas automaticamente quando o código é executado novamente.

Endereço da aplicacao na maquina local

Executando a aplicacao localmente

Agora vamos realizar o deploy da nossa pequena aplicação. Entretanto primeiro devemos criar a aplicação e reservar o espaço para ela nos servidores do Google através do portal do App Engine. Após realizar o login podemos criar a aplicação e reservar espaço para ela clicando no botão Create na Application. Seremos direcionados para uma tela onde deveremos informar o ID e nome da aplicação. Nesse ponto devemos tomar cuidado pois o ID da aplicação será o seu endereço e após criada não poderemos mais excluí-la, ocupando o espaço de uma das 10 aplicações possíveis de serem criadas na conta grátis. 

Criando uma aplicacao na nuvem do App Engine

Informando os dados de uma nova aplicacao

Reservado o espaço devemos voltar ao nosso projeto onde devemos alterar a propriedade application com o ID da nossa aplicação no App Engine. Essa propriedade de configuração é encontrada no arquivo appengine-web.xml que fica na pasta war\WEB-INF\lib. É através desse ID que a ferramenta de upload ou o Plugin para o Eclipse saberá em que aplicação ela realizá o deploy do nosso projeto.

Configurando o projeto para upload no App Engine

Alterada essa propriedade podemos então realizar o deploy clicando no botão com o símbolo do App Engine. Será aberta uma janela onde devermos informar o nome do projeto, nosso login e senha do App Engine. Informados esses dados devemos clicar no botão Deploy para iniciar o upload da aplicação. Finalizado esse processo temos nosso projeto publicado na nuvem e pronto para ser utilizado.

Iniciando o deploy pelo Eclipse

Informando os dados para iniciar o deploy

Deploy iniciado

Abrindo a aplicacao na nuvem

Testando a aplicacao na nuvem

Nesse post passamos pelos passos básicos para criar um projeto para o App Engine com o auxilio do Plugin para o Eclipse. Em post futuros continuaremos explorando as funcionalidades dessa plataforma. Como sempre deixei uma cópia dos fontes utilizados nesse post no meu Sky Drive, nesse caso com o nome AppEngine – HelloWorld.zip.

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

Silverlight: Consumindo serviços WCF em outros domínios

Olá a todos,

                Nesse post demonstraremos como uma consumir um serviço WCF a partir de uma aplicação desenvolvida em Silverlight no contexto em que estão hospedados em domínios diferentes. A explicação de como consumir um serviço WCF em Silverlight já foi abordada em outro post, porém nele nos limitamos hospedando o serviço e o consumidor no mesmo local de origem. Para montar a estrutura necessária para esse exemplo utilizarei duas roles do Windows Azure, portanto também demonstraremos como hospedar aplicações WCF e Silverlight no Windows Azure com o CTP de novembro, que trouxe algumas mudanças.

                Antes de iniciarmos nosso exemplo precisamos entender o motivo e como funciona a restrição no consumo de aplicações em outros domínios. Na verdade a restrição não é apenas para outros domínios, mas sim para outros “locais de origem”. Um local de origem nesse contexto é o conjunto de domínio, protocolo de comunicação e porta acessada. Essa regra existe nos browsers como medida de segurança para códigos JavaScript não acessarem recursos de outros locais de origem que possam ser maliciosos. Portanto ela é aplicada para aplicações desenvolvidas em Silverlight, Flash ou qualquer outra ferramenta que faça uso de JavaScript para acessar recursos na web. Logo quando temos uma aplicação desenvolvida em Silverlight e desejarmos acessar um serviço WCF ou outro recurso que esteja exposto em outro domínio, porta ou que utilize outro protocolo de comunicação nos depararemos com essa medida de segurança.

                Para lidarmos com essa restrição temos duas alternativas. A primeira é colocarmos um serviço WCF ou outro recurso no mesmo local de origem da aplicação Silverlight que consuma o serviço original que está no outro local de origem. A segunda alternativa é possibilitarmos o consumo desse recurso através da inclusão dos arquivos crosssdomain.xml e clientaccesspoliciy.xml. Porém esses arquivos devem ser adicionados no servidor que expõem o serviço, logo deveremos ter acesso a esse servidor ou ao publicador do serviço para adicioná-lo, caso contrário nos restará somente a primeira opção. O arquivos clientaccesspolicy.xml é exclusivo para aplicações escritas em Silverlight, já o arquivo crossdomain.xml pode ser utilizado para permitir ou restringir o acesso a qualquer aplicação que tente acessar o recurso através de JavaScript.

                Vamos agora iniciar o nosso exemplo que será um projeto do tipo Windows Azure Cloud Service e terá uma ASP .Net Web Role para hospedar a aplicação escrita em Silverlight e uma WCF Service Web Role para hospedar o serviço WCF. A aplicação será a mesma utilizada na demonstração de consumo de serviço WCF por aplicações em Silverlight no mesmo local de origem.

Criando o projeto principal

Adicionando as web roles na solucao

Estrutua inicial da solucao

Após criada a solução com os projetos devemos adicionar também o projeto da aplicação Silverlight. Durante esse processo devemos indicar para o Visual Studio que desejamos hospedar esse projeto na ASP .Net Web Role:

Adicionando o projeto da aplicacao Silverlight

Hospedando a aplicacao Silverlight na Web Role

Estrutura da solucao com o projeto silverlight

Em seguida vamos modificar a página principal do projeto Web para expor a aplicação Silverlight. Vamos utilizar o mesmo código já desenvolvido em outro post.

Codigo da pagina que hospeda a aplicacao Silverlight

XAML da aplicacao Silverlight

Partiremos agora para a construção do Serviço WCF que será hospedado na outra Web Role e que será disponibilizado em outra porta, portanto estará em outro local de origem. Nesse serviço teremos o mesmo método do post anterior sobre consumo de serviços WCF por aplicações Silverlight. Para essa tarefa vamos remover o serviço inicial disponibilizado pelo template e adicionar outro item do tipo Silverlight-enabled WCF Service: 

Adicionando o servico na Web Role

Codigo do servico WCF

Para finalizar a estrutura devemos adicionar a referência do serviço WCF na aplicação Silverlight. Para isso clique com o botão da direita sobre o projeto Silverlight e selecione a opção Add Service Reference e em seguida clique no botão Discover:

Adicionando a referencia do servico na aplicacao Silverlight

Agora adicionaremos o código para consumir o serviço a partir da aplicação Silverlight e em seguida tentaremos consumir o serviço. 

Codigo da aplicacao Silverlight

Porém como ainda não adicionamos os arquivos que permitem o consumo do serviço por código JavaScript de outros locais de origem nos deparamos com a seguinte exceção: System.ServiceModel.CommunicationException was unhandled by user code  Message=”An error occurred while trying to make a request to URI ‘http://localhost:8080/TesteSL.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.”

Mensagem de erro ao consumir recurso em outro local de origem

 A origem dessa exceção não o nosso código Silverlight ou WCF, mas sim a segurança do browser que não permite que um código JavaScript consuma recursos de outros locais de origem. Para permitir o consumo do serviço por nossa aplicação deveremos colocar os arquivos crossdomain.xml e clientaccesspolicy.xml no diretório raiz do site/aplicação que hospeda o serviço, no nosso caso a web role.

Arquivos clientaccesspolicy.xml e crossdomain.xml adicionados no projeto

Conteudo do arquivo clientaccesspolicy.xml

Note que no arquivo clientaccesspolicy.xml podemos definir quais URIs poderão acessar o recurso, no nosso caso o serviço WCF, além de configurar também quais os diretórios estarão acessíveis a essas URIs. Já no arquivo crossdomain.xml configuramos somente quais domínios terão acesso aos nossos recursos. 

Conteudo do arquivos crossdomain.xml

Adicionados os arquivos no projeto vamos testar novamente a solução, que funcionará corretamente.

Aplicacao funcionando corretamente

Com isso temos nossa aplicação Silverlight consumindo um serviço WCF em outro local de origem, que poderia ser em outro domínio também, desde que no servidor que hospeda o serviço tenhamos os arquivos para permitir o seu consumo. Como sempre deixei no meu Sky Drive os fontes utilizados para escrever o post, nesse caso o arquivo está com o nome LocaisOrigem.zip

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

 

 

 

 

App Engine: plataforma de clouding computing da Google

Olá a todos,

    A partir desse post começaremos a explorar também o App Engine, que é a plataforma de clouding computing do Google. Essa plataforma tem muitos conceitos parecidos com o Windows Azure pois ambas plataformas hospedam nossas aplicações em um ambiente altamente escalável, disponível e que podemos comprar sob demanda. No App Engine também podemos hospedar nossas aplicações web compostas de camada de apresentação, que são executadas na máquina cliente, e de camada de negócios, que é executada nos servidores do Google. Essa plataforma também possui um mecanismo de armazenamento de dados próprio, semelhantes às tables do Windows Azure Storage, projetado para suportar aplicações com enorme quantidade de usuários simultâneos e com alta performance.

    Podemos utilizar Java ou Python para desenvolver as aplicações que serão hospedadas no App Engine. Nos posts utilizarei somente Java, porém ambas as linguagem possuem todos os recursos da plataforma App Engine disponíveis, semelhante ao C# e VB .Net na plataforma Microsoft. Para os leitores que como eu escolherem desenvolver as aplicações em Java recomendo utilizarem o eclipse, pois há um plugin para esse IDE que auxilia nas tarefas rotineiras dos projetos.

    Após instalar o eclipse devemos instalar os pacotes para desenvolvimento em Java. No meu caso instalei os seguintes pacotes nessa ordem: java_ee_sdk-5_07-jdk-6u16-windows, jre-6u16-windows-i586, java_ee_sdk-5_04-windows_nojdk, java-tools. Após a instalação desses componentes podemos instalar o plugin do App Engine que adicionará no eclipse os seus templates. Duas vantagens da plataforma da Google é que ela possui a documentação básica em diversos idiomas, entre eles português, e que podemos utilizar uma determinada quantidade de espaço e tráfego sem custo. Com isso podemos estudar e praticar o desenvolvimento de aplicações para essa plataforma sem custos. Porém até o momento localizei somente a documentação básica e poucos exemplos com código fonte disponíveis, talvez porque comecei explorar essa plataforma a pouco tempo.

    Um pacote que tem me auxiliado no desenvolvimento dos testes é o Google Web Toolkit. Esse pacote provê objetos para compor a camada de apresentação e para montar a comunicação entre essa camada e a camada de negócio. Algo semelhante como utilizar ASP .Net com serviços em WCF, porém com protocolo de comunicação proprietário.

    Como já acontece com os posts sobre a plataforma Microsoft colocarei os códigos fonte dos exemplos utilizados na construção dos posts. No futuro pretendo praticar também a integração entre essas plataformas.

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

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.