Windows Communication Foundation Desenvolvimento de Aplicações para Web Rodrigo Cristiano Silva rodrigo@facens.br

WCF WCF Addresses TCP HTTP Contracts Service Contract Data Contract Bindings Basic Hosting IIS 5/6 Self-Hosting Endpoints Address Binding Contract Client Proxy

O que é o WCF? WCF é um SDK (Software Development Kit) para desenvolver e instalar serviços no Windows; WCF oferece um ambiente de execução para serviços, possibilitando que tipos da CLR (Common Language Runtime) sejam expostos como serviços e que serviços sejam consumidos como tipos da CLR; WCF é a implementação de um conjunto de padrões da indústria de software que definem como devem ser as interações com serviços, as conversões de tipos e gerenciamento de vários protocolos.

Serviços Um serviço é uma unidade de funcionalidade exposta ao mundo; Representam o próximo passo na longa jornada: funções → objetos → componentes → serviços; Uma aplicação orientada a serviços agrega serviços em uma única aplicação lógica, de forma similar, uma aplicação orientada a componentes agrega componentes e uma aplicação orientada a objetos agrega objetos.

Cliente de um Serviço O cliente de um serviço é meramente um programa que consome suas funcionalidades (métodos); Um cliente pode ser qualquer tipo de aplicação: Windows Forms, WPF, Silverlight, ASP.NET, Console ou outro serviço; Clientes e serviços interagem através do envio e recebimento de mensagens, usualmente mensagens SOAP. Tais mensagens são independentes do protocolo de transporte; Clientes WCF podem trabalhar com serviços desenvolvidos em outras tecnologias; Serviços WCF também podem trabalhar com clientes desenvolvidos em outras tecnologias.

Proxy Com WCF, o cliente nunca interage com o serviço diretamente, mesmo quando trata com um serviço local; O cliente sempre usa um proxy para encaminhar chamadas ao serviço; O proxy oferece as mesmas operações (métodos) que o serviço; Seus métodos são responsáveis por encapsular, de forma transparente, a criação e o envio de mensagens ao serviço.

Endereços No WCF, todo serviço é associado à um único endereço; O endereço possui dois elementos importantes: a localização do serviço e o protocolo de transporte; A parte do endereço referente à localização indica o nome da máquina alvo, uma porta de comunicação e um caminho específico opcional (URI); WCF suporta os seguintes protocolos de transporte: HTTP/HTTPS TCP IPC Peer network MSMQ Service bus

Endereços Endereços sempre têm o seguinte formato: [endereço base]/[URI opcional] O endereço base sempre tem o seguinte formato: [transporte]://[máquina ou domínio][:porta opcional] Alguns exemplos: http://localhost:8001/MyService net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe net.msmq://localhost/MyQueue

Endereços Endereços TCP: Endereços HTTP: Endereços IPC: Usam net.tcp para transporte e tipicamente incluem um número de porta. Quando uma porta não é especificada, o valor padrão é 808. Exemplo: net.tcp://localhost:8002/MyService Endereços HTTP: Usam http para transporte e também podem usar https para transporte seguro. Endereços HTTP são tipicamente utilizados em serviços que serão publicados na Internet. Se a porta não for especificada, o valor padrão é 80. Exemplo: http://localhost:8001/MyService Endereços IPC: Usam net.pipe para transporte indicando o uso do mecanismo Windows Named Pipe. Serviços que usam o IPC aceitam somente chamadas da mesma máquina, por isso, é necessário usar o nome da máquina ou localhost no endereço, seguido de uma string única que identifica o pipe. Exemplo: net.pipe://localhost/MyPipe

Contratos No WCF, todos os serviços expõem contratos; O contrato é uma forma padrão e independente de plataforma de descrever o que o serviço faz; WCF define quatro tipos de contratos: Service contracts: Descrevem quais operações o cliente pode realizar no serviço; Data contracts: Definem quais tipos de dados são passados do cliente para o serviço e vice-versa. WCF define contratos implícitos para tipos primitivos como int e string; Fault contracts: Definem quais erros são lançados pelo serviço e como o serviço manipula e propaga erros para seus clientes; Message contracts: Permitem que o serviço interaja diretamente com mensagens. São úteis nos casos de interoperabilidade, quando a outra parte impõe um formato explícito de mensagem (tipicamente proprietário). A menos que requisitos como maior flexibilidade e extensibilidade sejam necessários, message contracts devem ser evitados, pois eles não adicionam valor e adicionam complexidade.

Service Contract O atributo ServiceContractAttribute permite que se defina um contrato de serviço. O atributo pode ser aplicado em uma interface ou em uma classe, como mostra o exemplo abaixo:

Service Contract O atributo ServiceContract mapeia uma interface CLR para um contrato de serviço independente de tecnologia; O atributo ServiceContract expõe uma interface CLR como um contrato WCF independentemente de sua visibilidade (modificadores de acesso). Aplicar o atributo ServiceContract à uma interface internal expõe essa interface como um contrato de serviço público; Somente interfaces decoradas com o atributo ServiceContract serão consideradas contratos WCF, outros tipos não; Adicionalmente, nenhum dos membros da interface farão parte do contrato ao aplicar somente o atributo ServiceContract, é necessário indicar explicitamente quais métodos serão expostos no contrato WCF usando o atributo OperationContract; O atributo OperationContract pode somente ser aplicado à métodos.

Service Contract Uma única classe pode suportar múltiplos contratos implementando interfaces decoradas com o atributo ServiceContract, conforme exemplo abaixo:

Hosting Todo serviço WCF deve ser hospedado em um processo Windows chamado host process; Um único host process pode hospedar múltiplos serviços e o mesmo serviço pode ser hospedado em múltiplos host processes; Não existem restrições quanto a um host process também ser um client process. Chamamos esse tipo de hosting de in-process (ou in-proc) hosting; A hospedagem de um serviço WCF pode ser feita pelo: Internet Information Services (IIS) Windows Activation Service (WAS) Windows Server AppFabric Desenvolvedor como parte da aplicação (Self-hosting)

IIS 5/6 Hosting A principal vantagem de hospedar um serviço no IIS é que o host process é iniciado automaticamente quando a primeira requisição do cliente é disparada; A principal desvantagem é que somente o HTTP pode ser usado como protocolo de transporte; No IIS 5, ainda existe a restrição de que todos os serviços usam o mesmo número de porta; A hospedagem no IIS é bastante similar à hospedagem de um web service clássico. É necessário criar um diretório virtual no IIS e um arquivo .svc; O arquivo .svc funciona de forma similar ao arquivo .asmx, é usado para identificar o arquivo e a classe do code behind, segue exemplo:

IIS 5/6 Hosting O arquivo web.config tipicamente lista os tipos que se deseja expor como serviços, segue exemplo:

Self-Hosting Self-hosting é a técnica na qual o desenvolvedor é o responsável por prover e gerenciar o ciclo de vida do host process; É possível utilizar qualquer Windows process, tais como uma aplicação Windows Forms, WPF, Console ou um Windows Service; É importante ressaltar que o processo deve estar rodando antes do cliente fazer chamadas ao serviço. Isto não é um problema para um Windows Service ou para uma hospedagem in-proc; Diferentemente da hospedagem no IIS, um self-hosted service pode usar qualquer protocolo de transporte do WCF; Como na hospedagem IIS, o arquivo app.config tipicamente lista os tipos dos serviços que se deseja hospedar, segue exemplo:

Self-Hosting O host process deve registrar explicitamente o tipo do serviço em tempo de execução e abrir o host para receber as chamadas do cliente; A criação do host é tipicamente feita no método main() através da classe ServiceHost; É importante notar que cada instância de ServiceHost é associada com um tipo particular de serviço. Para hospedar vários tipos de serviço serão necessárias várias instâncias de ServiceHost; Ao executar o método Open() no host, inicia-se o tratamento das chamadas dos clientes; Ao executar o método Close(), a instância do host é finalizada, permitindo que as chamadas correntes terminem sua execução, enquanto novas chamadas são recusadas;

Self-Hosting Segue abaixo exemplo de código necessário para hospedar um serviço em uma aplicação Windows Forms:

Self-Hosting e Base Adresses É possível registrar múltiplos endereços base para um mesmo serviço, desde que não usem o mesmo protocolo de transporte: É possível registrar múltiplos hosts para um mesmo serviço, desde que usem endereços base diferentes:

Bindings Existem múltiplos aspectos e muitos possíveis padrões de comunicação para serviços WCF; Se todas as possíveis opções de comunicação e interação fossem contadas, provavelmente o número de combinações estaria na casa de dezenas de milhares; Claramente, cliente e serviço devem estar alinhados em todas as opções para que se estabeleça uma comunicação apropriada; Gerenciar este nível de complexidade não traz nenhum valor para maioria das aplicações, e ainda pode trazer implicações de produtividade e de qualidade severas caso decisões erradas sejam tomadas; Para simplificar essas escolhas e torná-las gerenciáveis, o WCF agrupa conjuntos de aspectos de comunicação em bindings; Um binding é meramente um conjunto de escolhas a respeito de protocolo de transporte, codificação da mensagem, padrão de comunicação, segurança, propagação de transações e interoperabilidade; Tudo que se precisa fazer é determinar o cenário alvo para o serviço e escolher um dos bindings oferecidos pelo WCF.

Bindings mais Comuns Basic binding: TCP binding: IPC binding: Representado pela classe BasicHttpBinding, é utilizado para expor um serviço WCF como um web service ASMX, assim clientes antigos podem trabalhar com serviços novos; TCP binding: Representado pela classe NetTcpBinding, usa o protocolo TCP para comunicação entre máquinas de uma intranet. É otimizado para comunicação WCF-to-WCF, entretanto, requer que ambos cliente e serviço usem WCF; IPC binding: Representado pela classe NetNamedPipeBinding, usa named pipes para a comunicação na mesma máquina; Web Service binding: Representado pela classe WSHttpBinding, usa HTTP ou HTTPS para transporte e oferece uma variedade de características ligadas a Internet, todas usando os padrões WS-*; MSMQ binding: Representado pela classe NetMsmqBinding, usa MSMQ para transporte e oferece suporte a chamadas desconectadas em fila.

Escolhendo um Binding

Usando Binding Existem três maneiras de trabalhar com bindings: Usar os bindings padrões como eles são; Configurar algumas das propriedades dos bindings, tais como propagação de transações e segurança; Escrever o próprio binding personalizado.

Endpoints Todo serviço é associado com um address que define onde o serviço está, um binding que define como se comunicar com o serviço e um contract que define o que o serviço faz; Esse triunvirato governando o serviço pode ser facilmente lembrado como ABC do serviço; O endpoint é a fusão do address, binding e contract.

Endpoints Todo serviço deve expor ao menos um endpoint e cada endpoint aceita somente um único contrato; Um serviço pode expor múltiplos endpoints, estes podem usar o mesmo ou bindings diferentes e podem expor o mesmo ou contratos diferentes; É importante ressaltar que nada no código do serviço pertence aos seus endpoints, e eles são sempre externos ao código do serviço; É possível configurar endpoints ou através de um arquivo de configuração (app.config ou web.config) ou programaticamente.

Endpoints Abaixo exemplo de arquivo de configuração definindo um serviço que expõe múltiplos endpoints:

Endpoints Abaixo exemplo de configuração de endpoints programaticamente:

Metadata Exchange Por padrão, o serviço não publicará seus metadados; Publicar os metadados de um serviço envolve um esforço significativo, uma vez que você tem que converter tipos CLR e informações de binding em WSDL, e todo esse esforço não agrega nenhum valor ao serviço; Felizmente, o host já sabe tudo o que precisa saber sobre um serviço e seus endpoints, então ele pode publicar os metadados se for explicitamente instruído a fazê-lo; Existem duas opções para publicar os metadados de um serviço: Usando HTTP-GET (protocolo baseado em texto suportado pela maioria das plataformas); Ou usando um endpoint dedicado.

Metadata usando HTTP-GET WCF pode gerar os metadados de um serviço usando HTTP-GET automaticamente; Basta habilitar explicitamente essa funcionalidade, adicionando um behavior ao serviço; Por padrão, o endereço que os clientes devem usar para acessar os metadados é o registrado como endereço HTTP base do serviço; Uma vez habilitada a troca de metadados através do HTTP-GET, é possível acessar o endereço base do serviço através de um browser, mesmo que se tenha feito a hospedagem do serviço usando a técnica de self-hosting.

Metadata usando HTTP-GET Segue abaixo exemplo de como habilitar essa funcionalidade:

Metadata Exchange Endpoint Publicação de metadados usando HTTP-GET é meramente uma funcionalidade do WCF, não há garantias que outras plataformas suportarão essa maneira de expor os metadados; Existe uma maneira de publicar metadados através de um endpoint especial chamado metadata exchange endpoint; Tudo que se precisa fazer é determinar o endereço e o binding e adicionar o metadata behavior; Para o binding, o WCF oferece suporte aos protocolos HTTP, HTTPS, TCP e IPC; Para o endereço, é possível usar um endereço completo ou qualquer endereço base registrado.

Metadata Exchange Endpoint Abaixo exemplo que expõe três MEX endpoints:

WCF Test Host O Visual Studio 2010 traz consigo um host de serviço de propósito geral; O executável é chamado WcfSvcHost.exe; WcfSvcHost é um utilitário de linha de comando que aceita dois parâmetros: O caminho do assembly que contém a classe do serviço; O caminho do arquivo de configuração do host; Exemplo de comando: WcfSvcHost.exe /service:MyService.dll /config:App.config O assembly especificado pode ser uma class library (DLL) ou uma aplicação (EXE).

WCF Test Host Uma vez executado, o WcfSvcHost coloca um ícone na barra de tarefas do Windows e, ao clicar nesse ícone, uma caixa de diálogo aparece listando todos os serviços hospedados; No painel Debug das propriedades do projeto é possível especificar o WcfSvcHost.exe como programa externo a ser inicializado; A maior vantagem de usar o WcfSvcHost é que durante o desenvolvimento, não será necessário desenvolver um projeto de host separado; A maior desvantagem é que ele somente pode ser usado em cenários simples nos quais não é necessário: Acesso a instância do host antes de abri-lo; Acesso ao modelo de eventos após aberto.

Programação no Cliente Para executar operações em um serviço, um cliente precisa importar o contrato do serviço; Se o cliente usa WCF, a forma mais comum de executar operações é usar um proxy; O proxy é uma classe CLR que expõe uma única interface CLR que representa o contrato do serviço; Se o serviço suporta vários contratos, o cliente precisa de um proxy para cada contrato; O proxy encapsula todos os aspectos do serviço como sua localização, tecnologia de implementação e regras de comunicação.

Gerando o Proxy O Visual Studio 2010 permite importar os metadados do serviço e gerar um proxy usando a opção Add Service Reference do menu de contexto do projeto; Se o serviço foi hospedado usando a técnica de self-hosting e não faz parte da mesma solution, é necessário executar a aplicação que hospeda o serviço e, após isso, selecionar a opção Add Service Reference; Se o serviço é self-hosted e faz parte da mesma solution, é necessário executá-lo sem o debugger antes de selecionar a opção Add Service Reference; Se o serviço é hospedado no IIS 5/6 ou WAS, não há necessidade de executá-lo antes de criar o proxy; Na tela Add Service Reference especifica-se o endereço dos metadados do serviço e o namespace no qual o proxy será criado. Ao clicar no botão OK, o Visual Studio criará o proxy e atualizará o arquivo de configuração; Uma vez adicionada uma referência, o projeto apresentará uma nova pasta Service References e nela existirá um item para cada serviço;

Proxy usando SvcUtil Uma alternativa para importar os metadados e criar o proxy é usar a ferramenta de linha de comando SvcUtil.exe; Por exemplo, se o serviço MyService está hospedado no IIS e publica seus metadados através do HHTP-GET, pode-se executar o seguinte comando para gerar o proxy: SvcUtil http://localhost/MyService/MyService.svc /out:Proxy.cs

Configuração do Cliente O cliente precisa saber onde o serviço está hospedado, deve usar o mesmo binding que o serviço e, é claro, importar a definição do contrato do serviço; Na essência, isto é exatamente a mesma informação usada no endpoint do serviço. Para refletir isso, o arquivo de configuração do cliente pode usar as mesmas configurações usadas no endpoint do host; O WCF oferece um editor de arquivos de configuração chamado SvcConfigEditor.exe, que pode editar os arquivos de configuração do host e do cliente. Pode ser executado através do Visual Studio clicando com o botão direito do mouse sobre o arquivo de configuração e selecionando Edit WCF Configuration; Abaixo exemplo de arquivo de configuração no cliente:

SvcConfigEditor

Trabalhando com Proxy Para o usar o proxy, o cliente precisa instanciar um objeto proxy passando para o construtor o nome da seção endpoint do arquivo de configuração; Em seguida, o cliente pode usar métodos do proxy para chamar métodos do serviço e, após o término da execução do método, o cliente precisa fechar o proxy, conforme exemplo:

WCF Test Client O Visual Studio 2010 traz consigo um simples cliente de propósito geral que pode ser usado para executar operações na maioria dos serviços; O cliente é chamado de WcfTestClient.exe e pode ser executado conforme exemplo abaixo: WcfTestClient.exe http://localhost:9000/

WCF Test Client