Esta é a parte 2 de uma série de posts sobre WCF. Leia a parte 1.
Depois da introdução sobre WCF na parte 1 desta série, vamos examinar quais os processos envolvidos na solicitação e na execução de um serviço, e depois examinaremos como modelar um sistema que seja dividos nestes processos. Na parte 3 finalmente iremos codificar e analisar o código de cada um dos processos em questão. Este post está dividido nas seguintes sessões:
Hello WCF: Arquitetura de Processos: quais são as aplicações que compõem nossa aplicação distribuída, e como elas se comunicam.
Hello WCF: Arquitetura do Código: Como está organizado o código destas aplicações.
Hello WCF: Arquitetura de Processos
Vamos primeiro entender quais são os processos envolvidos na nossa primeira aplicação WCF. Estamos disponibilizando um serviço na rede que executa a espetacular operação de gerar a string Hello WCF!!! toda vez que é invocado. Um dos requisitos do nosso serviço é que ele possa ser invocado de qualquer máquina da nossa rede, então pelo menos duas máquinas estarão envolvidas no processamento: o cliente e o hospedeiro (mas vou chamar esta última de host porque “hospedeiro” doeu fundo no ouvido ;-). O cliente é a máquina que solicita o serviço, e o host é a máquina aonde o serviço é executado.
Fig.1 – As máquinas cliente e host.
Na verdade, não são máquinas que se comunicam, mas sim processos rodando nestas máquinas. Facilita o entendimento pensar como sendo dois processos em máquinas diferentes (Fig. 2), mas neste nosso teste ambos os processos, cliente e host, estarão rodando na mesma máquina.
Fig.2 – Os processos cliente e host.
WCF torna a comunicação entre os processos envolvidos o mais transparente possível. Neste caso, iremos usar o protocolo HTTP para a comunicação entre clientes e host. Ao usarmos WCF na nossa aplicação host, os objetos do namespace System.ServiceModel já provêem quase tudo que é necessário para que o host receba pedidos de execução de serviços provenientes de HTTP.SYS, que é o componente do IIS que recebe os pedidos de comunicação HTTP e os despacha para o “processo certo”. Você verá no código do host como ele avisa ao IIS que está esperando pedidos de acesso, e aonde ele está esperando – é o conceito de endpoint, que é o ponto de chegada de pedidos de acesso a um serviço WCF.
Fig.3 – Ao usar HTTP, o endpoint é gerenciado por HTTP.SYS, que envia o pedido de acesso ao serviço para o processo host.
Como a escolha do protocolo de comunicação é um detalhe de implementação, na próxima figura vamos retirar HTTP.SYS do esquema. A figura 4 retrata as trocas de mensagens entre cliente e host, e como o serviço é disponibilizado:
- É criada uma classe na aplicação host que representa o serviço (ServicoHelloWCF);
- Este serviço disponibiliza uma série de operações, que são os métodos da classe que implementa o serviço. Neste caso, nosso serviço tem apenas uma operação, cuja assinatura é: string HelloWCF() – ou seja, uma operação chamada HelloWCF, que não recebe parâmetros e retorna uma string.
- O cliente envia uma mensagem de execução de uma operação ao processo host; o processo instancia a classe que implementa o serviço, executa o método que corresponde à operação desejada, e retorna o resultado para o cliente.
Fig.4 – A execução de uma operação de um serviço WCF.
Hello WCF: Arquitetura do Código
O código de nossa aplicação exemplo será dividido em 3 projetos: duas aplicações Console e uma Class Library.
As aplicações Console representam o cliente e o host, os dois processos se comunicando. A aplicação Class Library representa o contrato do serviço. O contrato do serviço é uma descrição – atenção meninos, descrição, e não implementação – do serviço oferecido pelo host. Já comentamos antes que um serviço WCF é um conjunto de operações, sendo o serviço implementado por uma classe, e as operações implementadas pelos métodos desta classe. O contrato do serviço descreve esta classe e seus métodos, mas não os implementa. Tanto o cliente quanto o host tem que conhecer os detalhes do serviço sendo invocado. O cliente tem que saber quais operações ele pode invocar, e como elas devem ser invocadas. O host tem que implementar exatamente o que o cliente espera invocar. Ou seja, ambos, cliente e host, tem que conhecer e obedecer à descrição do serviço. Desta forma, aparece o terceiro projeto na nossa solução, que nada mais é do que uma Class Library compartilhada entre cliente e host, que contém uma interface que define o contrato do serviço: quais as operações que cada serviço oferecido deve implementar.
Fig.5 – Usaremos uma Class Library para compartilhar uma interface (ITesteWCF) que descreve o service contract.
Veja que ambos os projetos, o Cliente e o Host, usam a interface ITesteWCF que contém o contrato do serviço. O Cliente usa a inteface para saber como chamar o serviço; e o Host a utiliza criando uma classe que implementa esta interface, desta forma criando uma classe que implementa o serviço oferecido.
No próximo post veremos o código de cada um destes projetos: o contrato do serviço, o host e o cliente.
Update: Apesar de esta postagem ser antiga, notei que recentemente o acesso a ela tem aumentado. Infelizmente, o envolvimento em outros projetos parou meu estudo de WCF. Por isto, não escrevi a sequência de artigos sobre WCF que iria se iniciar com este post. Espero que quando entrarmos em um projeto que use WCF eu volte para esta série.
Atenciosamente,
GB
