Cenários síncronos utilizando HTTP, TCP ou pipe nomeado

Este tópico descreve as atividades e transferências de diferentes cenários de solicitação/resposta síncrona, com solicitações um cliente de thread único, usando HTTP, TCP ou pipe nomeado. Consulte Cenários assíncronos usando HTTP, TCP ou pipe nomeado para obter mais informações sobre solicitações multi-threaded.

Solicitação/resposta síncrona sem erros

Esta seção descreve as atividades e transferências para um cenário de solicitação/resposta síncrona válido, com um cliente de thread único.

Cliente

Estabelecendo a comunicação com o ponto de extremidade de serviço

Um cliente é construído e aberto. Para cada uma dessas etapas, a atividade ambiente (A) é transferida para uma atividade "Construct Client" (B) e uma atividade "Open Client" (C), respectivamente. Para cada atividade que está sendo transferida, a atividade ambiente é suspensa até que haja uma transferência de volta, ou seja, até que o código ServiceModel seja executado.

Fazendo uma solicitação para o ponto de extremidade de serviço

A atividade ambiente é transferida para uma atividade "ProcessAction" (D). Dentro dessa atividade, uma mensagem de solicitação é enviada e uma mensagem de resposta é recebida. A atividade termina quando o controle retorna ao código do usuário. Como essa é uma solicitação síncrona, a atividade ambiente é suspensa até que o controle retorne.

Fechando a comunicação com o ponto de extremidade de serviço

A atividade fechar (I) do cliente é criada com base na atividade ambiente. Isso é idêntico a novo e abrir.

Servidor

Configurando um host de serviço

As atividades novo e abrir (N e O) do ServiceHost são criadas com base na atividade ambiente (M).

Uma atividade de ouvinte (P) é com base na abertura de um ServiceHost para cada ouvinte. A atividade do ouvinte aguarda para receber e processar dados.

Recebendo dados na transmissão

Quando os dados chegam à transmissão, uma atividade "ReceiveBytes" será criada se ainda não existir (Q) para processar os dados recebidos. Essa atividade pode ser reutilizada para várias mensagens em uma conexão ou fila.

A atividade ReceiveBytes iniciará uma atividade ProcessMessage (R) se ela tiver dados suficientes para formar uma mensagem de ação de SOAP.

Na atividade R, os cabeçalhos da mensagem são processados e o cabeçalho activityID é verificado. Se esse cabeçalho estiver presente, a ID da atividade será definida como a atividade ProcessAction; caso contrário, uma ID será criada.

A atividade ProcessAction (S) é criada e transferida quando a chamada é processada. Essa atividade termina quando todo o processamento relacionado à mensagem de entrada é concluído, incluindo a execução do código do usuário (T) e o envio da mensagem de resposta, se aplicável.

Fechando um host de serviço

A atividade fechar (Z) do ServiceHost é criada com base na atividade ambiente.

Em <A: nome>, A é um símbolo de atalho que descreve a atividade no texto anterior e na tabela 3. Name é um nome abreviado da atividade.

Se propagateActivity=true, a Ação de Processo no cliente e no serviço terá a mesma ID de atividade.

Solicitação/resposta síncrona com erros

A única diferença com o cenário anterior é que uma mensagem de falha SOAP é retornada como mensagem de resposta. Se propagateActivity=true, a ID da atividade da mensagem de solicitação será adicionada à mensagem de falha SOAP.

Unidirecional síncrono sem erros

A única diferença com relação ao primeiro cenário é que nenhuma mensagem é retornada ao servidor. Para protocolos baseados em HTTP, um status (válido ou erro) ainda é retornado ao cliente. Isso ocorre porque HTTP é o único protocolo com uma semântica de solicitação-resposta que faz parte da pilha de protocolos do WCF. Como o processamento TCP está oculto do WCF, nenhuma confirmação é enviada ao cliente.

Unidirecional síncrono com erros

Se ocorrer um erro durante o processamento da mensagem (Q ou posterior), nenhuma notificação será retornada ao cliente. Isso é idêntico ao cenário "Unidirecional síncrono com erros". Não use um cenário unidirecional se quiser receber uma mensagem de erro.

Duplex

A diferença com relação aos cenários anteriores é que o cliente atua como um serviço, pois ele cria as atividades ReceiveBytes e ProcessMessage, semelhante aos cenários assíncronos.