Cenários síncronos usando HTTP, TCP ou Named-Pipe
Este tópico descreve as atividades e transferências para diferentes cenários de solicitação/resposta síncrona, com um cliente de thread único, usando HTTP, TCP ou pipe nomeado. Consulte Cenários assíncronos usando HTTP, TCP ou Named-Pipe 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 cliente de thread único.
Cliente
Estabelecendo comunicação com o Service Endpoint
Um cliente é construído e aberto. Para cada uma dessas etapas, a atividade ambiental (A) é transferida para uma atividade "Construct Client" (B) e "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 ao Service Endpoint
A atividade ambiental é 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 ambiental é suspensa até que o controle retorne.
Fechando a comunicação com o Service Endpoint
A atividade de proximidade do cliente (I) é criada a partir da atividade ambiental. Isto é idêntico ao novo e aberto.
Servidor
Configurando um host de serviço
As atividades novas e abertas do ServiceHost (N e O) são criadas a partir da atividade ambiental (M).
Uma atividade de ouvinte (P) é criada a partir da abertura de um ServiceHost para cada ouvinte. A atividade do ouvinte aguarda para receber e processar dados.
Recebendo dados no fio
Quando os dados chegam ao fio, uma atividade "ReceiveBytes" é criada se ainda não existir (Q) para processar os dados recebidos. Essa atividade pode ser reutilizada para várias mensagens dentro de uma conexão ou fila.
A atividade ReceiveBytes inicia uma atividade ProcessMessage (R) se tiver dados suficientes para formar uma mensagem de ação SOAP.
Na atividade R, os cabeçalhos das mensagens são processados e o cabeçalho activityID é verificado. Se esse cabeçalho estiver presente, o ID da atividade será definido como a atividade ProcessAction; caso contrário, uma nova ID será criada.
A atividade ProcessAction (S) é criada e transferida para, quando a chamada é processada. Esta atividade termina quando todo o processamento relacionado com a mensagem recebida é concluído, incluindo a execução do código de utilizador (T) e o envio da mensagem de resposta, se aplicável.
Fechando um host de serviço
A atividade de fechamento (Z) do ServiceHost é criada a partir da atividade do 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, Process Action no cliente e no serviço tiverem o mesmo 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 uma mensagem de resposta. Se propagateActivity=true, o ID de atividade da mensagem de solicitação é adicionado à mensagem de falha SOAP.
Unidirecional síncrono sem erros
A única diferença com o primeiro cenário é que nenhuma mensagem é retornada ao servidor. Para protocolos baseados em HTTP, um status (válido ou de 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 protocolo 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 superior), nenhuma notificação será devolvida ao cliente. Isso é idêntico ao cenário "Synchronous One-Way without Errors". Você não deve usar um cenário unidirecional se quiser receber uma mensagem de erro.
Duplex
A diferença com os cenários anteriores é que o cliente atua como um serviço, no qual cria as atividades ReceiveBytes e ProcessMessage, semelhante aos cenários assíncronos.