Olá pessoal!
O objetivo 3.8, Implement messaging patterns, trata de Message Exchange Patterns (ou Padrões de Troca de Mensagem), que são mecanismos que descrevem como o client e o server vão se comunicar.
Vamos cobrir como implementar os tipos one-way, request/reply, streaming e duplex, além de falar sobre alguns mecanismos no Azure. Vamos lá?
Implementando One-Way, Request/Reply, Streaming e Duplex
One-Way
Implementações one-way servem para cenários fire and forget, onde você faz uma chamada e não se importa com a resposta, como escrever alguma coisa em um log.
O WCF suporta implementações one-way de forma simples. Basta setar o parâmetro IsOneWay como true no atributo OperationContract e não ter nenhum tipo de retorno no método:
[OperationContract(IsOneWay = true)]
void LogMessage(String message);
Num cenário comum, um request é feito para o servidor que processa e envia um response. Com OneWay, acontece o seguinte: quando o request é feito, o servidor responde instantaneamente com o StatusCode 202, Accepted. Só depois disso ele vai de fato processar o request, como se fosse uma operação assíncrona.
Apesar de ser uma boa feature, OneWay deve ser usado com cuidado. Operações críticas podem dar errado sem que você saiba, causando problemas. Bons candidatos a OneWay são operações de baixa prioridade e que não retornam valor.
Streaming
Ao implementar streaming com WCF, você tem dois modos para trabalhar: Buffered ou Streaming.
Buffered, o modo default, significa que a mensagem inteira precisa ser enviada para que o recebedor comece a leitura. Em Streaming, o recebedor consegue começar a leitura assim que a informação estiver disponível (cenário ideal para transferência de arquivos grandes, como áudio ou vídeo).
Nesse formato, uma propriedade importante é a maxReceivedMessageSize, que limita o tamanho de mensagens recebidas. Isso é crucial para evitar ataques DDoS.
No nível do contrato, você começa o processo definindo o retorno de um método como Stream. Depois é necessário configurar o binding para que o TransferMode seja Streamed e aí configurar o atributo maxReceivedMessageSize. O arquivo de configuração ficaria assim:
Há 4 valores para o enum TransferMode, com nomes bem sugestivos: Buffered, Streamed, StreamedRequest e StreamedResponse.
Um ponto para se ter em mente é que habilitar streaming para um serviço não vai automaticamente melhorar a performance. É verdade que com streaming não são necessários grandes buffers de memória, mas num contexto comum de transferência de informações a melhora de performance é imperceptível.
Outro aspecto é que nem todos os bindings suportam a propriedade TransferMode. Os únicos bindings padrão que aceitam são BasicHttpBinding, NetTcpBinding e NetNamedPipeBinding.
Por último, há algumas limitações ao se usar streaming. São elas:
- Operações que usam o transporte Streamed só podem ter um input e um output de parâmetro;
- Headers SOAP são sempre buffered, mesmo habilitando streaming. Eles não podem ultrapassar o tamanho da propriedade MaxBufferSize;
- As implementações de segurança Reliable Message e SOAP Message confiam na transmissão buffered. Geralmente você deve usar segurança no nível de transporte (objetivo 3.4).
Request/Reply
É o modo padrão de funcionamento de qualquer web service, onde o client envia um request, o server processa e envia um response. Não há muito a mais o que ser dito 😀 Vamos para o próximo item.
Duplex
Na comunicação duplex, o client se conecta com um serviço provendo um canal de comunicação, onde o server pode mandar mensagens de volta para o client. Para funcionar, tudo isso precisa existir no contexto de uma sessão.
Nesse cenário com WCF, além de definir um contrato de ServiceContract, outra interface é necessária para especificar a propriedade CallbackContract, que serve como callback. Para o exame, não é necessário saber mais que isso existe.
Implementando Azure Service Bus E Azure Queues
Como visto no objetivo anterior, o Azure Service Bus é um componente que conecta serviços WCF (e outras aplicações) pelo Azure.
Usando relay, a comunicação é feita diretamente entre as duas partes. Isso implica que ambas precisam estar online para a comunicação acontecer.
Às vezes, você precisa de uma fila de comunicações ou usar um mecanismo de publish/subscribe. O Azure também oferece essas tipos de comunicações.
Uma Queue (fila) permite que mensagens enviadas por um client sejam armazenadas até que outro client as leia. Um Topic extende o comportamento da queue adicionando subscriptions, onde cada client especifica critérios para filtrar as mensagens que vê. Como Topics não estarão no exame, vamos focar na Queue.
Quando usando uma Queue, você manda uma mensagem para o service bus com um conjunto de propriedades chave/valor e um body binário. A mensagem é armazenada pelo service bus e entregada a um recebedor em um determinado momento, desacoplando as duas (ou mais) aplicações. O recebedor pode remover o item da fila na leitura ou colocar um lock, processar a mensagem e depois removê-la (como o Storage Queue faz).
Questões sobre a implementação não são prováveis de estar no exame, então o conhecimento do mecanismo já é suficiente. Você pode obter mais detalhes aqui.
O conceito importante é o uso da classe QueueClient que permite o envio e recebimento de mensagens da queue. A mensagem é representada pela classe BrokeredMessage.
E chegamos ao final desse objetivo.
O próximo post, sobre o objetivo Host and manage services, será o último do capítulo sobre WCF.
Até mais!