Esta secção descreve o lado do cliente num canal de comunicação. Tal como no lado do servidor, também nesta secção se apresenta uma visão estática do mecanismo de comunicação.
Figure: Modelo de distribuição: cliente (visão estática).
Um diferença importante para o caso do servidor está no facto de enquanto, por interface e por contexto, apenas existe um SIF, o número de CIFs é variável para cada contexto. Assim, existe um CIF por cada par formado por um contexto remoto e uma dada interface, i.e., tantos quantos os canais de ligação do contexto aos seus interlocutores. Um CIF é criado sempre que o identificador único do seu interlocutor ainda não estiver associado a nenhum outro CIF, para uma interface e para o mesmo contexto. Cada CIF partilha o identificador único do SIF correspondente.
Apesar de poder existir um número indeterminado de canais de saída de contexto, um associado a cada CIF, existe apenas um canal de retorno, aquele que está associado ao SIF. Todos os contextos que comuniquem através de uma dada interface têm que partilhar o mesmo SIF, no contexto de destino. A tabela de clientes de interface (TCIF) mantém informação sobre os caminhos existentes para fora do contexto.
A acção do lado do cliente resume-se à tradução do identificador de um envelope remoto para um envelope local, i.e., à criação de um envelope equivalente ao envelope remoto correspondente à identificação dada. O ponto de partida é sempre o identificador do envelope remoto.
Se, durante o processo de importação, for encontrado no contexto local, na tabela do SIF correspondente, o objecto referido pelo identificador, i.e., se o objecto for um servidor local, então a acção do lado do cliente resume-se ao retorno da referência local para o objecto em causa. Este é uma situação muito particular em que um contexto passa um seu objecto numa chamada ``remota'' a si próprio. Neste caso o par envelope/representante degenera no par envelope/carta. Esta é a situação ilustrada no contexto 1, na figura 5.5.
Se não se verificar a condição anterior, o passo seguinte é verificar, na tabela de clientes conhecidos (TCC), se algum dos envelopes locais correspondentes a envelopes remotos contém a mesma identificação interna, i.e., se o objecto remoto já foi previamente importado. No caso de ter sido é retornado o que esteja nessas condições. Esta acção tem duas consequências importantes: apenas existe, num dado contexto, um representante de um objecto remoto; e, é possível comparar referências remotas para um dado objecto, obtidas por caminhos diferentes. Na realidade o que se passa é que uma das referências é desprezada, i.e., apenas se mantendo a que foi importada em primeiro lugar. É esta a situação que se verifica no contexto 3 da figura 5.5: o envelope correspondente ao ponto de comunicação <GID2:LID2> já tinha sido importado quando o que faria a ligação a <GID3:LID3> foi recebido na chamada remota. Dizendo ambos respeito ao objecto em <GID1:LID1>, apenas se manteve o primeiro.
Se nenhuma das situações anteriores tiver lugar, então é criado um novo envelope que é preenchido com a identificação interna do objecto representado e registado na TCC, sendo depois retornado aos níveis superiores como nos casos anteriores. A tabela de envelopes é partilhada por todos os CIFs de uma dada interface num dado contexto. Na figura 5.5, os contextos 2 e 4 limitam-se a criar novos envelopes, uma vez que o objecto não está local nem existem duplicados.
Figure: Casos de localização de envelopes a partir de CIFs.
Note-se que, na figura 5.4, os representantes que aparecem em substituição das cartas servem apenas para efectuar a preparação da invocação remota, definindo também qual o caminho que a mensagem vai seguir. A definição do caminho deve-se ao facto de estarem directamente associados a um dos CIFs, como se pode apreciar na figura 5.5.
A forma de comunicação entre o mecanismo de transporte e os CIFs é, tal como no lado do servidor, deixada para ser apresentada quando for descrita a realização concreta do módulo.