Olá!
Hoje vamos falar sobre o objetivo 3.5 da certificação 70-487, Consume WCF services.
Esse objetivo cobre como consumir um serviço WCF de 3 formas: gerando classes proxy com Svcutil.exe, gerando classes proxy adicionando uma referência ao serviço e consumindo via ChannelFactory. Vamos lá?
Gerando Proxies Com Svcutil.exe
É possível consumir serviços WCF gerando uma classe proxy e interagindo com ela como se fosse uma classe comum, deixando o framework fazer toda a comunicação por trás.
O Svcutil.exe, uma ferramenta chamada pela linha de comando, é uma das formas de gerar classes proxy de um serviço WCF. É possível fazer a geração baseado em serviços existentes ou metadata.
A ferramenta também permite que você exporte metadata de um serviço, valide código de um serviço, faça download dos metadatas de serviços existentes e gere código de serialização.
A melhor maneira de estudar para o exame é criar alguns serviços e gerar as proxies chamando o Svcutil.exe com opções diferentes, analisando o que a ferramenta de fato faz. A lista abaixo traz as opções importantes para o exame ao chamar a ferramenta pela linha de comando (atalhos estão entre parênteses):
- /directory:<directory> (/d): especifica o diretório em que os arquivos gerados serão colocados. Se não for especificado, o diretório atual será usado. Caso o diretório já tenha sido usado, o Svcutil.exe irá sobrescrever os arquivos;
- /mergeConfig: caso o diretório já tenha sido usado, ao invés de sobrescrever os arquivos, com essa opção o Svcutil.exe irá fazer o merge das configurações;
- /help (/?): lista as opções disponíveis;
- /noLogo: tira as informações Logo (copyright e mensagem de banner);
- /svcutilConfig:<configFile>: coloca as configurações no arquivo especificado. O default é o App.config;
- /target:<output type> (/t): instrui a ferramenta a criar um output específico. As opções são code, metadata e xmlSerializer;
- /async (/a): cria todos os métodos das classes proxy com a versão normal e uma Async;
- /internal (/i): cria todos os métodos das classes proxy como internal, e não public;
- /serializer (/ser): gera os tipos com um serializer específico. As opções são Auto, DataContractSerializer e XmlSerializer;
- /out (/o): especifica o nome do arquivo para o código gerado;
- /language (/l): especifica uma linguagem para o código gerado. As opções são c#, cs, csharp, vb, visualbasic, c++ e cpp.
Gerando Proxies Por Referência
Uma feature do Visual Studio é a possibilidade de gerar classes proxy adicionando uma referência a um serviço.
Basta clicar com o botão direito no seu projeto e ir em Add Service Reference. A seguinte tela é mostrada:
Você pode prover uma URL de um serviço (com metadata habilitado) ou clicar no botão Discover para encontrar services que estão na mesma solution. Após clicar em Go, os serviços são listados e você pode especificar um namespace, o que é recomendado.
Ao clicar em Advanced abaixo, a tela Service Reference Settings é aberta:
No topo você pode especificar o modificador de acesso e se métodos async devem ser gerados, como as opções /internal e /async usando Svcutil.exe.
A opção Always Generate Message Contracts faz o que o nome diz, gera classes para os contratos.
Na seção Data Type, você pode definir o tipo das coleções. Nada te impede de usar generics (List<T>), mas geralmente arrays são utilizados para manter a compatibilidade entre diferentes clients que não sejam .NET.
A última seção, Compatibility, serve se você estiver consumindo um web service antigo .asmx. A tela Add Web Reference é aberta:
Criando E Implementando ChannelFactories
A classe ChannelFactory serve para fazer comunicações com endpoints de forma simples. Ela pode atuar em conjunto com o arquivo de configuração da sua aplicação, fazendo com que uma chamada a um serviço tenha 2 linhas de código.
A primeira coisa que você deve saber é que a classe ChannelFactory trabalha com o contrato do serviço, então você deve ter uma referência à interface que especifica o contrato.
Construtores
O construtor padrão não aceita nenhum parâmetro, então informações sobre o endpoint precisam ser especificadas: new ChannelFactory.
O próximo aceita uma string com o nome de configuração do endpoint:
String endpointConfigName = "wsHttp_BindingConfig";
ChannelFactory<ITestService> proxy = new ChannelFactory<ITestService>(endpointConfigName);
Outro aceita um binding, mas funciona da mesma forma:
String endpointConfigName = "wsHttp_BindingConfig";
WSHttpBinding wSBinding = new WSHttpBinding(EndpointConfigName);
ChannelFactory<ITestService> proxy = new ChannelFactory<ITestService>(wSBinding);
O próximo aceita um ServiceEndpoint:
ServiceEndpoint endpoint = new ServiceEndpoint(new ContractDescription("Endpoint"));
ChannelFactory<ITestService> proxy = new ChannelFactory<ITestService>(endpoint);
Há outros construtores que são bem intuitivos. Vamos a um cenário real de uso da classe ChannelFactory, algo bem provável de conter pelo menos 1 questão no exame:
O método CreateChannel inicializa a ChannelFactory, retornando o tipo do contrato especificado no construtor. Depois disso, basta chamar os métodos desejados que estão no contrato. Por fim, chame o método Close. Ele possui uma chamada padrão sem parâmetros e uma recebendo um TimeSpan, onde você indica que se o canal não for fechado nesse tempo uma exceção é lançada.
Por último, é importante destacar que com ChannelFactory você não precisa da classe de definição do serviço, apenas a interface do contrato.
Isso é tudo para esse objetivo 🙂
Obrigado pela leitura e fique de olho no post do próximo objetivo, Version a WCF service.
Até mais!