Visão geral do modelo de canal

A pilha de canais do Windows Communication Foundation (WCF) é uma pilha de comunicação em camadas com um ou mais canais que processam mensagens. Na parte inferior da pilha há um canal de transporte que é responsável por adaptar a pilha de canais ao transporte subjacente (por exemplo, TCP, HTTP, SMTP e outros tipos de transporte). Os canais fornecem um modelo de programação de baixo nível para enviar e receber mensagens. Este modelo de programação depende de várias interfaces e outros tipos conhecidos coletivamente como o modelo de canal WCF. Este tópico discute as formas de canal, a construção de um escutador básico de canal (no serviço) e de uma fábrica de canal (no cliente).

Pilha de canais

Os pontos de extremidade do WCF comunicam-se com o mundo através de uma pilha de comunicação conhecida como pilha de canais. O diagrama a seguir compara a pilha de canais com outras pilhas de comunicação, por exemplo, TCP/IP.

Primeiro, as semelhanças: em ambos os casos, cada camada da pilha fornece alguma abstração do mundo abaixo dessa camada e expõe essa abstração apenas para a camada diretamente acima dela. Cada camada usa a abstração de apenas a camada diretamente abaixo dela. Também em ambos os casos, quando duas pilhas se comunicam, cada camada se comunica com a camada correspondente na outra pilha, por exemplo, a camada IP se comunica com a camada IP e a camada TCP com a camada TCP, e assim por diante.

Agora, as diferenças: Enquanto a pilha TCP foi projetada para fornecer uma abstração da rede física, a pilha de canais é projetada para fornecer uma abstração não apenas de como a mensagem é entregue, ou seja, o transporte, mas também outros recursos, como o que está na mensagem ou qual protocolo é usado para comunicação, incluindo o transporte, mas muito mais do que isso. Por exemplo, o elemento seguro de vinculação de sessão faz parte da pilha de canais, mas não está abaixo do transporte ou do próprio transporte. Essa abstração é alcançada exigindo que o canal inferior na pilha adapte o protocolo de transporte subjacente à arquitetura da pilha de canais e, em seguida, confiando em canais mais acima na pilha para fornecer recursos de comunicação, como garantias de confiabilidade e segurança.

As mensagens fluem através da pilha de comunicação como objetos Message. Como mostrado na figura acima, o canal inferior é chamado de canal de transporte. É o canal responsável por enviar e receber mensagens de e para terceiros. Isso inclui a responsabilidade de transformar o Message objeto de e para o formato usado para se comunicar com outras partes. Acima do canal de transporte, pode haver qualquer número de canais de protocolo, cada um responsável por fornecer uma função de comunicação, como garantias de entrega confiáveis. Os canais de protocolo operam em mensagens que fluem através deles na forma de objeto Message. Eles normalmente transformam a mensagem, por exemplo, adicionando cabeçalhos ou criptografando o corpo, ou enviam e recebem suas próprias mensagens de controle de protocolo, por exemplo, confirmações de recebimento.

Formas de canal

Cada canal implementa uma ou mais interfaces conhecidas como interfaces de forma de canal ou formas de canal. Esses tipos de canal fornecem os métodos orientados para a comunicação, como enviar e receber, ou solicitar e responder, que o canal implementa e que o utilizador do canal invoca. Na base das configurações do canal está a IChannel interface, que é uma interface que fornece um método GetProperty<T>, destinado como um mecanismo em camadas para acessar funcionalidades arbitrárias expostas por canais na estrutura. As cinco formas de canal que se estendem IChannel são:

• IInputChannel

• IOutputChannel

• IRequestChannel

• IReplyChannel

• IDuplexChannel

Além disso, cada uma dessas formas tem um equivalente que se expande System.ServiceModel.Channels.ISessionChannel<TSession> para suportar sessões. São eles:

• IInputSessionChannel

• IOutputSessionChannel

• IRequestSessionChannel

• IReplySessionChannel

• IDuplexSessionChannel

As formas do canal são padronizadas de acordo com alguns dos padrões fundamentais de troca de mensagens suportados pelos protocolos de transporte existentes. Por exemplo, mensagens unidirecionais correspondem a um IInputChannel/IOutputChannel par, solicitação-resposta corresponde a IRequestChannel/IReplyChannel pares, e comunicações duplex bidirecionais correspondem a IDuplexChannel (que se estende a ambos IInputChannel e IOutputChannel).

Programação com o Channel Stack

As pilhas de canais são normalmente criadas usando um padrão de fábrica onde uma ligação cria a pilha de canais. No lado de envio, uma ligação é usada para construir um ChannelFactory, que, por sua vez, cria uma pilha de canais e retorna uma referência ao canal superior na pilha. O aplicativo pode usar esse canal para enviar mensagens. Para obter mais informações, consulte Client Channel-Level Programming.

No lado do recebimento, uma ligação é usada para criar um IChannelListener, que escuta as mensagens recebidas. O IChannelListener fornece mensagens para a aplicação que está a escutar, criando pilhas de canais e passando a referência da aplicação para o canal no topo. Em seguida, o aplicativo usa esse canal para receber mensagens recebidas. Para obter mais informações, consulte Service Channel-Level Programming.

O modelo de objeto do canal

O modelo de objeto de canal é o conjunto principal de interfaces necessárias para implementar canais, ouvintes de canal e fábricas de canais. Há também algumas classes base fornecidas para ajudar em implementações personalizadas.

Os ouvintes do canal são responsáveis por ouvir as mensagens recebidas e, em seguida, entregá-las à camada acima através dos canais criados pelo ouvinte do canal.

As fábricas de canais são responsáveis por criar canais que são usados para enviar mensagens e fechar todos os canais que criaram quando a fábrica de canais é fechada.

ICommunicationObject é a interface principal que define a máquina de estado básica que todos os objetos de comunicação implementam. CommunicationObject fornece uma implementação dessa interface principal que outras classes de canal podem derivar em vez de reimplementar a interface. No entanto, isso não é necessário: um canal personalizado pode implementar ICommunicationObject diretamente e não herdar do CommunicationObject. Nenhuma das classes da Figura 3 é considerada parte do modelo de canal; Eles são auxiliares disponíveis para implementadores de canal personalizados que desejam criar canais.

Os tópicos a seguir descrevem o modelo de objeto de canal, bem como várias áreas de desenvolvimento que ajudam a criar canais personalizados.

Tópico	Descrição
Serviço: Ouvintes de Canal e Canais	Descreve os ouvintes de canal, que escutam canais de entrada em um aplicativo de serviço.
Cliente: Fábricas de canais e canais	Descreve as fábricas de canais, que criam canais para estabelecer ligação com uma aplicação de serviço.
Noções básicas sobre alterações de estado	Descreve como a interface System.ServiceModel.ICommunicationObject modela alterações de estado nos canais.
Escolhendo um padrão de troca de mensagens	Descreve os seis padrões básicos de troca de mensagens que os canais podem suportar.
Tratamento de exceções e falhas	Descreve como lidar com falhas e exceções em canais personalizados.
Suporte a Configuração e Metadados	Descreve como dar suporte ao uso de canais personalizados do modelo de aplicativo e como exportar e importar metadados usando associações e elementos de ligação.