Nesse post vamos demonstrar como podemos ter transações distribuídas utilizando serviços WCF sendo propagadas para chamadas de diversos métodos que podem pertencer a diferentes serviços. Esse cenário pode ser desenvolvido utilizando dois modelos: um proprietário do WCF para situações onde existirão somente serviços construídos nessas tecnologia e outro utilizando o protocolo WS-AT (WS Atomic Transaction), que é um protocolo de controle de transações compatível com diversas tecnologias para desenvolvimento de webservices.

A estrutura de transação do WCF (para os dois tipo de protocolos citados acima) utiliza o modelo presente a partir do .Net Framework 2.0, onde temos dois tipos de objetos: Transacion e TransactionScope. Nesse modelo de programação o desenvolvedor normalmente lida com o objeto TransactionScope pois a duração da transação e as operações transacionadas são determinadas pela vida desse tipo de objeto. Temos nesse tipo de objeto três propriedades básicas que podem ser configuradas: seu período de timeout (TransactionTimeout), seu nível de isolamento (TransactionIsolationLevel) e se ela será confirmada automaticamente ou não (TransactionAutoCompleteOnSessionClose).

Para um método de um serviço WCF pertencer a uma transação ele deve ser decorado com o atributo TransactionFlow, onde deve ser informado a obrigatoriedade ou não da transação. Essa configuração é informada a partir de um parâmetro, que pode assumir três valores diferentes, passado para o atributo. O valor Allowed indica que um método pode ou não pertencer a uma transação, desse modo quando a chamada desse método pertencer a uma transação as operações realizadas por ele também estarão no contexto da transação. Porém se a chamada não pertencer a uma transação o método será executado com suas operações não transacionadas. O valor NotAllowed informa que o método não será executado em contexto de transação, ou seja, mesmo que a chamada possua uma transação ativa as operações realizadas pelo método com esse valor não estarão no contexto dessa transação nem de qualquer outra. Por último o valor Mandatory obriga o método a possuir uma transação. Nessa configuração caso a chamada não possua uma transação ativa será iniciada uma nova transação com o escopo desse método.

Passaremos agora para o desenvolvimento do nosso exemplo. Nele teremos dois serviços WCF onde cada um possuirá um método que pode ser chamado no contexto de uma transação. Um dos métodos faz a inserção em um banco de dados enquanto o outro enviará uma mensagem para uma fila MSMQ. Demonstraremos então o funcionamento da transação distribuída utilizando mais de um recurso. Começaremos então criando uma fila transacional no MSMQ e uma tabela em um banco de dados no SQL Server.

Codigo para gerar a tabela utilizada no exemplo

O próximo passo é construir a estrutura para o código que será composta de um Windows Service para hospedar os serviços WCF e de uma aplicação do tipo Console que será o iniciador das chamadas, controlando a transação. Adicionados esses projetos na solução adicione dois serviços WCF no projeto do Windows Service e faça as alterações necessárias nesse projeto para subir os serviços. Nesse exemplo as configurações serão controladas a partir do arquivo app.config dos projetos.

Estrutura da solucao

Adicionados os dois serviços WCF no projeto do Windows Service vamos iniciar as configurações para que eles suportem chamadas em contexto de transação. O primeiro item a ser alterado é o contrato de cada serviço. Nele será adicionado o atributo TransactionFlow na definição do método, especificando o seu suporte a transações. Essa alteração deve ser realizada para os contratos dos dois serviços.

Codigo do contrato do primeiro servico

Após a alteração dos dois contratos devemos modificar também o código da sua implementação, adicionando o atributo TransactionScopeRequired para o método.

Codigo inicial do metodo do segundo servico

Basta agora alterarmos o arquivo app.config do Windows Service para termos nossos serviços WCF suportando transações. Nessa configuração será alterada a configuração do binding, passando o valor do atributo transactionFlow como true e informando essa configuração nos endpoints:

Modificacoes no arquivo de configuracao

Vamos então terminar o código dos serviços, onde o primeiro fará a inserção no banco de dados e o segundo enviará uma mensagem para o MSMQ, ambos no contexto de uma transação:

Codigo para enviar a mensagem em contexto de transacao

Codigo para inserir o registro na tabela

Passaremos agora a desenvolver a chamada da aplicação que inicia essa transação. Nesse exemplo utilizamos um projeto do tipo Console Application, porém outros tipos de projetos podem ser utilizados. O primeiro passo é gerar os proxies dos serviços, para isso podemos iniciar a versão de Debug do Windows Service a partir de uma linha de comando, solicitando ao Visual Studio a geração dos proxies dos dois serviços. Após gerados os proxies basta criar um objeto do tipo TransactionScope e realizar as chamadas dos serviços durante o seu ciclo de vida, como demonstrado abaixo:

Codigo da aplicacao que controla a transacao

Temos então nosso exemplo pronto. Podemos iniciar o Windows Service para abrir os serviços. Em seguida execute a aplicação que inicia a transação e realiza as chamadas. Poderemos ver que ao final da execução será adicionado um registro na tabela e será enviada a mensagem para a fila. Vamos agora retirar o comentário da linha de código na aplicação console para forçar o disparo de uma exceção com o intuito de forçar o rollback da transação. Ao executar todo o ciclo novamente veremos que a exceção foi disparada e não foi incluído o registro na tabela nem enviada a mensagem para a fila. Como sempre adicionei o exemplo no meu Sky Drive com o nome WCF_Transacional.

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

                Nesse post falaremos mais um pouco sobre o mecanismo de armazenamento de dados do App Engine. Demonstraremos como montar relacionamentos do tipo “um para muitos” nessa estrutura de armazenamento. Primeiro precisamos lembrar que o mecanismo do App Engine não é uma base de dados relacional, portanto precisamos pensar de uma maneira diferente quanto projetamos nossa estrutura de dados.

                Numa base de dados relacional temos cada entidade representada por uma tabela e os relacionamentos são dados por chaves primárias e estrangeiras. Num relacionamento do tipo “um para muitos”, onde temos um “pai” para muitos “filhos” temos na tabela “filho” um ou mais campos que compõem a chave estrangeira. Essa chave então aponta para os campos que compõem a chave primária no registro na tabela “pai”. Portanto o relacionamento é montado através de relacionamento entre os campos dos registros. Um ponto importante é que cada entidade permanece separada em uma tabela.

                Já na base de dados do App Engine temos uma estrutura orientada a objetos. Nesse tipo de base de dados as entidades são representadas por classes, que são as mesmas utilizadas no código do aplicativo. Portanto os relacionamentos entre os objetos são montados de outra maneira. Num relacionamento do tipo “um para muitos” o objeto “pai” contém os objetos “filhos” que podem estar organizados em arrays ou listas dinâmicas.

                Vamos então passar para o exemplo para deixar essas idéias mais claras. O primeiro passo é criar o projeto no eclipse. Nesse post utilizaremos um projeto do App Engine sem o uso do GWT. Esse projeto seguirá a sugestão do Rodrigo Monteiro feita em um comentário do post anterior. Porém alterei o tipo de relacionamento de “um para um” para “um para muitos”.

                Criado o projeto temos que definir nossa estrutura de dados, que será composta por um conjunto de classes. A classe “pai” representará livros, enquanto a classe “filho” serão os capítulos desse livro (na sugestão do Rodrigo a classe pai era Departamento e a classe filho Funcionario). Para montar o relacionamento entre o livro e seus capítulos (um livro para N capítulos) deveremos criar uma lista da classe capítulos na classe livro. Porém para permitir a identificação do relacionamento entre as classes pelo mecanismo de armazenamento deveremos criar uma propriedade do tipo livro na classe capitulo. O relacionamento é estabelecido ao utilizarmos o parâmetro mappedBy do atributo Element na propriedade da classe “pai” que representa seus filhos, ou seja, na lista de capitulos. Esse parâmetro recebe uma string que é o nome da propriedade que armazena o objeto “pai” no “filho”. A implementação dessa estrutura pode ser vista na figurar abaixo:

Codigo das classes que serao persistidas no App Engine

                Podemos então passar para a criação e armazenamento dos objetos. Para demonstrar vamos criar um objeto do tipo livro e adicionarmos nele alguns objetos do tipo capitulo. Após adicionarmos os objetos “filhos” no objeto “pai” devemos utilizar a classe PersistenceManager para persistir a classe “pai”. Nesse tipo de relacionamento não é necessário persistir as classes filhos, pois elas já serão persistidas junto com a classe “pai”. O código para realizar essa tarefa é semelhante ao abaixo:

Codigo para gravar os objetos no storage

                Podemos realizar as pesquisas a partir da classe “pai” ou pela classe “filho”, porém não podemos utilizar atributos da classe “filho” quando nossa consulta parte da classe “pai”. Abaixo temos um exemplo de como realizar a pesquisa nessa estrutura de dados:

Codigo para realizar a pesquisa

                Temos então um exemplo de relacionamento “um para muitos” no App Engine. Um ponto importante é primeiro projetarmos as classes para somente depois começarmos a utilizá-las. Como sempre deixei o código utilizado para construir o post no meu Sky drive, com o nome testeJDO.zip.

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

                Em outros posts sobre o App Engine mostramos como desenvolver a camada de apresentação com o uso de páginas JSP ou com o Framework GWT. Também já fizemos um teste simples construindo uma regra de negócio no lado Server, que comunica com a camada de apresentação através do protocolo RPC, que é proprietário do GWT. Por fim fizemos nossa primeira integração entre plataformas comunicando a camada de apresentação, desenvolvida com o uso do GWT, com um serviço WCF através do protocolo REST utilizando o formato JSON.

Arquitetura com os assuntos demonstrado ate o momento

                Entretanto até o momento não tínhamos abordado a camada de persistência. Esse será o assunto desse post, onde veremos como podemos gravar as informações de nossos sistemas no Data Storage do App Engine. Para manipular os dados armazenados nesse Data Storage temos duas opções: podemos utilizar APIs de baixo nível diretamente ou através da biblioteca JDO. Como esse é o primeiro post em que abordamos o assunto utilizaremos a biblioteca JDO.

                O App Engine Data Storage é um mecanismo que nos permite gravar os dados de forma estruturada. A estrutura dos dados é definida através de classes, portanto o Data Storage não é um banco de dados relacional. Porém podemos utilizar comandos de pesquisa muito semelhantes ao transact SQL para realizar pesquisas nessa base de dados. Na verdade esse mecanismo de persistência de dados é muito semelhante às tables do Windows Azure Data Storage e ao banco de dados Caché.

               A principal vantagem do App Engine Data Storage em relação ao mecanismo do Windows Azure é a possibilidade de aninharmos tipos de dados. Assim no App Engine podemos criar uma classe, que define uma estrutura de dados, onde algumas de suas propriedades podem ser outras classes que também definem estruturas de dados do Data Storage. Para exemplificar: podemos criar uma classe (estrutura) endereço e utilizá-la como propriedade em outra classe, que seria do tipo pessoa. A classe pessoa poderia também possuir uma lista (List) de endereços. Desse modo podemos utilizar o Data Storage do App Engine como um banco de dados hierárquico preparado para lidar com altíssimo volume de acessos.

                Nosso exemplo será um cadastro de logins, com os campos login e senha. Alteraremos uma tela já utilizada na nossa prova de conceito adicionando os controles necessários para esse exemplo.

               A primeira tarefa que devemos realizar é definir nossa estrutura de dados através de uma classe. Essa classe deverá ser criada na subpasta client (lembre-se que estamos utilizando o GWT). Para indicar que essa classe será utilizada pelo JDO devemos decorá-la com o atributo PersistenceCapable. Além disso devemos decorar com o atributo Persistent cada variável membro dessa classe que desejamos persistir no Data Storage.

Classe que define a estrutura dos dados que serao gravados

               Toda classe definida como uma estrutura de dados do Data Storage deve possuir um campo de identificador único, semelhante à uma primary key em um banco de dados relacional. Porém a variável membro que será o identificador único deverá ser decorada com o atributo PrimaryKey. Nesse ponto temos duas observações importantes. Primeiro, por limitação do GWT para utilizarmos a passagem de objetos entre as camadas (client e Server) o tipo de dado da variável que será a primary key não poderá deverá ser do tipo Key. Segundo, esse campo não poderá ser um tipo nativo, como string ou long, mas sim classes que representem esses tipos como String ou Long.

               O próximo passo será alterar a tela adicionando os controles para permitir a pesquisa e inclusão dos dados. Incluiremos um botão para realizar a pesquisa e outro botão para gravar um novo login ou atualizar algum já existente. Deverão ser adicionados caixas de texto para que possamos digitar o login e senha que serão gravados e uma tabela que exibirá os logins já criados.

                A terceira etapa é escrevermos a classe que faz o uso do JDO. Como estamos utilizando o Eclipse com o plugin do App Engine as configurações no projeto para utilizarmos o JDO já estão preparadas para nós. Caso necessite ou queira saber como realizar as configurações pode ser vista aqui. A comunicação com o JDO é realizada através de objetos do tipo PersistenceManager, que são criados através do objeto PersistenceManagerFactory. Porém o objeto do tipo PersistenceManagerFactory demanda um tempo razoável para criá-lo, em contrapartida precisamos somente de uma instância dele para todo o projeto. Portanto podemos encapsular esse objeto em um classe, que deverá ser criada na subpasta Server, modificada com o atributo final para termos somente uma instância dessa classe na memória do nosso processo.

Classe para recuperar os objetos do tipo PersistenceManager

               A última etapa é escrevermos o código para gravar e pesquisar os dados no Data Storage. Para gravarmos um novo dado devemos criar uma nova instância da classe e atribuir valores às suas propriedades. Em seguida temos que obter uma instância da classe PersistenceManager para em seguida gravarmos os dados através do método makePersistent desse objeto. A atualização de dados deve ser realizada com o mesmo método, porém utilizando uma instância recuperada do Data Storage.

Codigo para gravar os dados no Data Storage

               Para pesquisarmos os dados no Data Storage precisamos montar uma query de pesquisa semelhante a uma query transact SQL, porém utilizamos nome de classes no lugar de nome de tabelas. Deveremos então obter uma instância da classe PersistenceManager e executarmos o método newQuery, passando como parâmetro a query. O retorno será uma lista (List) do tipo de objeto que define a estrutura dos dados.

Codigo para pesquisar os dados no Data Storage

               Restará apenas escrever o código para realizar a chamada dos métodos do lado Server, conforme já demonstrado em outro post. Poderemos então gravar novos dados e pesquisar os dados já existentes. Temos então um exemplo simples de como gravar e pesquisar dados no mecanismo de persistência do App Engine. Demonstramos também como trafegar objetos complexos entre as camadas do GWT. O código-fonte utilizado nesse post está disponibilizado no meu Sky Drive com o nome POCAppEngine JDO.zip.

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

Olá a todos

                No último post (a muito tempo atrás) demonstramos como utilizar o protocolo REST junto com o formato JSON para realizar a comunicação entre a camada de apresentação em Silverlight e serviços WCF. Naquele post ficamos restritos na plataforma Microsoft.

                A partir desse post vamos fazer algo um pouco diferente. Começaremos a partir de agora com o desenvolvimento de integrações entre plataformas. Nesse post faremos a integração entre a plataforma Microsoft e a plataforma App Engine através do protocolo REST.

Teremos então na plataforma Microsoft um serviço WCF que utiliza o protocolo REST e que expõem suas respostas no formato JSON. Utilizaremos nesse exemplo o serviço desenvolvido no último post. Já na plataforma App Engine utilizaremos a camada de apresentação desenvolvida em JAVA com o framework GWT. Outro ponto que testaremos é a integração on premise com on the cloud, pois o serviço WCF ficará em um servidor local (on premise) enquanto a camada de apresentação será construída para ser hospedada no data Center da Google.

                Como utilizaremos o serviço criado em outro post não descreveremos sua construção. Também aproveitaremos o exemplo sobre GWT desenvolvido em outro post para focarmos na integração das plataformas com o uso de REST e JSON. Assim passaremos direto para as alterações na camada de apresentação.

                Primeiro devemos adicionar um botão na tela para disparar a requisição ao serviço. Ele será adicionado na tela principal do exemplo sobre GWT (classe MainPanel.java). Devemos então declarar esse botão como variável membro da classe, além de configurar suas propriedades e adicionar o handler de click. Não esqueça também de adicionar esse botão no painel.

Adicionando o botao para disparar a requisicao ao servico

                O evento associado ao click do mouse dispara nesse exemplo um método chamado RealizaRequisicao, que é um método membro da classe MainPanel.java. Como o nome desse método diz ele realizará a requisição ao serviço WCF e tratará o retorno dessa requisição. A primeira etapa para a chamada do serviço é formar o endereço da requisição. Lembre que utilizamos o protocolo REST, logo todos os parâmetros serão passados no endereço. Nesse ponto é importante utilizarmos o método Encode da classe URL para realizar a troca de caracteres especiais (como acentos) pelos respectivos códigos para a requisição funcionar corretamente.

                Formado o endereço devemos utilizar um objeto da classe RequestBuilder para enviar a requisição ao serviço WCF. Ao realizar a requisição devemos informar um método de callback para ser disparado quando a resposta dessa requisição retornar. Esse método deve possuir dois eventos: onResponseReceive, que será disparado quando a requisição retornar com sucesso, e onError, que será disparado quando ocorrer um erro na requisição.

Estrutura inicial do metodo que realiza a requisicao ao servico

                Vamos focar agora no evento onResponseReceive, mostrando como realizar o tratamento da resposta da requisição. Primeiro precisamos recuperar a string JSON retornada pelo serviço, que é realizado através do método getText do objeto response, que é recebido como parâmetro do evento.

Comparando a classe client (JAVA) com a classe Server (C#)

                O segundo passo no tratamento da string JSON é declarar outro método na classe MainPanel. Esse método fará a transformação da string JSON em objetos JAVA, semelhante ao que fizemos em Silverlight no post passado. Lembre que os códigos javascript que estão no comentário também serão trocados durante a tradução de JAVA para javascript pelo GWT. 

Codigo para converter a string JSON em objetos

                Com a conclusão desses dois passos temos a estrutura para convertemos a string JSON em objetos JAVA. Porém antes devemos realizar um tratamento na string JSON para retirar alguns trechos que são adicionados pelo WCF e que são desnecessários no GWT. Esse tratamento é a retirada do início da string até o colchetes “[“ e do trecho a partir do último colchete “]” até o final da string. Para deixar o exemplo simples contei quantos caracteres deveriam ser retirados no início e no fim da string.

Tratamento da string JSON antes da conversao em objetos

                O passo final é utilizarmos a estrutura criada para converter a string tratada em objetos JAVA. Porém não podemos converter a string em um array de objetos diretamente. A conversão deve ser realizada para o tipo JsArray, que utilizará o nosso objeto como template. No exemplo recuperei o tamanho do array e percorri cada item recuperando uma propriedade para mostrar como trabalhar com os objetos que são o retorno da conversão. 

Codigo para converter a string JSON em objetos e utiliza-los

                Podemos agora testar o exemplo. Adicione alguns breakpoints no código JAVA e também um breakpoint no método do serviço WCF. Assim poderemos ver todo o fluxo do exemplo.

                Temos nesse ponto um exemplo simples, que pode ser estendido para cenários mais complexos, de interoperabilidade entre a plataforma Microsoft e a plataforma Google + JAVA através de REST. Como sempre deixei os fontes utilizados, nesse caso com o nome WCF_JSON_GWT.zip, no post no meu Sky drive.

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

                Nesse post vamos falar mais um pouco sobre WCF e como consumir serviços em aplicações Silverlight. Os cenários de serviços WCF cobertos até o momento trafegavam dados pelo protocolo SOAP ou por integração com o MSMQ. Demonstraremos nesse post como construir serviços WCF que utilizem o protocolo REST e trafegam dados no formato JSON. Demonstraremos também como consumir serviços com essa configuração em aplicações desenvolvidas em Silverlight.

REST é um protocolo de comunicação sendo uma alternativa ao protocolo SOAP, há um post interessante do Waldemir sobre o assunto. Já JSON é um formato de encapsulamento de dados, que pode ser visto como uma alternativa ao XML, tendo como principal vantagem a menor quantidade de dados trafegados entre o serviço e o consumidor. Sendo assim ele pode ser indicado para uso em cenários com largura de banda restrita.

                Começaremos nosso exemplo criando uma solução nova e adicionando um projeto do tipo Silverlight. Criaremos também um projeto Web que usaremos para hospedar nosso serviço WCF. Teremos então um cenário ainda não coberto no blog, que é a hospedagem de serviços WCF em aplicações Web. Outra característica é que o serviço WCF e a aplicação Silverlight estarão no mesmo local de origem, portanto não há a necessidade de expormos o arquivo crossdomain.xml ou ClientAccessPolicy.xml.

                Adicionaremos no projeto Web um serviço WCF, que no exemplo chamei de Usuario. Para expor as funcionalidades desse serviço através do protocolo REST e utilizar o formato JSON devemos realizar algumas alterações no contrato. Primeiro acrescentaremos os parâmetros Namespace e Name ao atributo ServiceContract. Outra alteração será na declaração do método que receberá o atributo WebInvoke para utilizar o protocolo REST. Nos parâmetros desse atributo deverá ser informado o verbo que disparará o método, nesse caso GET e o tipo de formato de resposta, que será JSON. Com esse último parâmetro poderemos ter como retorno dos métodos objetos comuns, deixando a cargo do WCF a serialização desses objetos em string JSON.

 Utilizamos o parâmetro UriTemplate no atributo WebInvoke para formatar como será realizada a chamada ao método e como serão passados seus parâmetros. Para informar a posição de um parâmetro para o método devemos utilizar o nome desse parâmetro entre chaves. O restante da string que não são os nomes dos parâmetros, que devem estar entre as chaves, será utilizado para formar a Uri de requisição. Logo se temos um método que recebe um parâmetro chamado valor e formamos a string do UriTemplate como MeuServicoe/{valor} a sua chamada desse método deverá ser realizada pelo endereço base do serviço (ex. localhost:8080) seguido do template. Portanto a Uri da requisição será HTTP://localhost:8080/MeuServico/123, onde 123 será o valor passado para o parâmetro. Note que a Uri não precisa conter o nome do método. Para uso do atributo WebInvoke nos métodos do contrato devemos adicionar o assembly System.ServiceModel.Web.

Codigo do contrato do servico

Para demonstrarmos o uso do JSON o método retornará uma string nesse formato que representa um array de objetos. Portanto criamos uma classe para representar os objetos que serão retornados pelo método.

Codigo da classe para tafegaros objetos

Passaremos agora para a implementação do serviço. A classe que implementará o serviço deverá ser decorada com o atributo ServiceBehavior que deverá receber o parâmetro AddressfilterMode como Any, desabilitando o filtro da origem das requisições. O método então receberá o parâmetro name, que será utilizado no construtor de um objeto do tipo MeuUsuario e retornará um array dessa classe através de uma string no formato JSON.

Codigo do servico

Resta agora configurar o serviço para ser exposto na aplicação Web. As configurações devem ser realizadas no arquivo web.config onde o endpoint deverá utilizar o binding webHttpBinding e possuir habilitada a configuração webHttp, essas configurações são necessárias para utilizar o protocolo REST.

Trecho do arquivo web.config com as configuracoes do servio

Após realizar a configuração podemos testar o serviço. Coloque um break point no método do serviço para vermos quando ele será invocado. Em seguida inicie a aplicação em modo debug, com isso será aberta uma janela de um browser de internet. Troque o nome da página pelo nome do serviço (com a extensão .svc, pois estamos em uma aplicação Web) e complete com o UriTemplate, substituindo os nomes dos parâmetros pelo valores que serão passados para o método. Veja que o método será disparado, recebendo os parâmetros informados na Uri.

Barra de endereco do browse com a URL inicial do projeto

Barra de endereco do browser com a URI para chamada do servico

Break point para acompanhar a chamada do servico

Temos então um serviço WCF que utiliza o protocolo REST e disponibiliza o resultado de seu método em uma string no formato JSON. Podemos passar para a construção do cliente que irá consumir esse serviço. Antes, porém para simplificar o desenvolvimento vamos fixar a porta em que o projeto web, e conseqüentemente o serviço WCF, será disponibilizado. Essa configuração é realizada nas propriedades do projeto Web, na aba Web e selecionando a opção Specific Port. Assim tanto a aplicação Silverlight como o serviço WCF responderão sempre a partir dessa porta pré-determinada.

Alterando as propriedades do projeto WEB

Iremos agora alterar o projeto Silverlight para consumir o serviço. Primeiro vamos alterar a interface com o usuário através do arquivo XAML, onde adicionaremos uma lista para receber e mostrar os objetos e um botão para disparar o consumo do serviço. Em seguida deveremos escrever o código que fará a requisição e mostrará os objetos na lista.

Codigo XAML da aplicacao Silverlight

O código utiliza um objeto do tipo WebClient para realizar a requisição. Esse objeto pode ser utilizado para realizarmos qualquer tipo de requisição HTTP. Porém as requisições são assíncronas, como quando utilizarmos os proxys gerados pelo Visual Studio. Logo antes de realizar a requisição devemos associar um método ao evento disparado quando o resultado dessa chamada é recebido.

Codigo para realizar a chamada ao servico

Recebemos da chamada um objeto do tipo Stream. Nesse exemplo vamos transformá-lo em uma string e em seguida des-serializar os objetos a partir dessa string. Utilizei para des-serializar a string um método que chamei de Deserialize. Ele recebe a string JSON como parâmetro e o tipo de objeto que deve ser retornado como generic e utiliza a classe DataContractJsonSerializer para realizar a tarefa. Essa classe pode ser utilizada para serializar objetos em string JSON também. Note que no método que faz os tratamentos da resposta, disparado pelo evento, existe um trecho que remove uma parte da string. Esse tratamento é necessário, pois o WCF incluiu na resposta da chamada um trecho de texto que identifica o nome do método chamado. E é exatamente esse trecho que é removido no código com as operações de string.

Codigo para receber e tratar a resposta do servico

Podemos agora testar nossa aplicação Silverlight. Devemos iniciar o projeto web e clicar no botão da aplicação. Será enviada uma requisição para o serviço, que responderá com a string JSON representando os objetos. A aplicação Silverlight fará a des-serialização dos objetos e os mostrará em uma lista. Temos então uma pequena aplicação desenvolvida em Silverlight que consome um serviço WCF utilizando protocolo REST com os dados trafegados no formato JSON. O exemplo utilizado nesse post está disponível no meu Sky Drive com o nome WCF_JSON.zip.

Teste da aplicacao

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

                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.

                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!

                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.  

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 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.

                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.