Detalhes de Organização

Caso utilize o marshaling padrão, o COM trata de todos os detalhes descritos aqui por si. No entanto, existem aqueles poucos programadores que precisam desses detalhes e para aqueles interessados nas informações subjacentes. Marshaling é o processo de agrupamento e desagrupamento de parâmetros para que uma chamada de procedimento remoto possa ocorrer.

Diferentes tipos de parâmetros são organizados de maneiras diferentes. Por exemplo, empacotar um parâmetro inteiro envolve simplesmente copiar o valor para o buffer de mensagens. (Ainda que mesmo neste caso simples existam problemas como a ordenação de bytes a resolver em chamadas entre computadores.) O empacotamento de uma matriz, no entanto, é um processo mais complexo. Os membros da matriz são copiados em uma ordem específica para que o outro lado possa reconstruir a matriz exatamente. Quando um ponteiro é empacotado, os dados para os quais o ponteiro está apontando são copiados seguindo regras e convenções para lidar com ponteiros aninhados em estruturas. Existem funções exclusivas para lidar com a organização de cada tipo de parâmetro.

Com o marshaling padrão, os proxies e stubs são recursos de todo o sistema para a interface e interagem com o canal através de um protocolo padrão. O marshaling padrão pode ser usado tanto por interfaces definidas pelo COM padrão como por interfaces personalizadas, da seguinte forma:

• No caso da maioria das interfaces COM, os proxies e stubs para marshaling padrão são objetos componentes em processo que são carregados de uma DLL do sistema fornecida pela COM em Ole32.dll.
• No caso de interfaces personalizadas, os proxies e stubs para marshaling padrão são gerados pelo designer de interface, normalmente com MIDL. Esses proxies e stubs são configurados estaticamente no Registro, para que qualquer cliente em potencial possa usar a interface personalizada através dos limites do processo. Esses proxies e stubs são carregados a partir de uma DLL que é localizada através do registo do sistema, usando o ID de interface (IID) para a interface personalizada que eles manipulam.
• Uma alternativa ao uso do MIDL para gerar proxies e stubs para interfaces personalizadas, uma biblioteca de tipos pode ser gerada em vez disso e o mecanismo de marshaling orientado por biblioteca de tipos fornecido pelo sistema irá organizar a interface.

Como alternativa ao marshaling padrão, uma interface (padrão ou personalizada) pode usar o marshaling personalizado. Com o marshaling personalizado, um objeto implementa dinamicamente os proxies em tempo de execução para cada interface suportada. Para qualquer interface dada, o objeto pode selecionar o marshaling padrão fornecido pela COM ou um marshaling personalizado. Essa escolha é feita pelo objeto em uma base de interface por interface. Uma vez que a escolha é feita para uma determinada interface, ela permanece em vigor durante o tempo de vida do objeto. No entanto, uma interface num objeto pode usar marshaling personalizado, enquanto outra usa marshaling padrão.

O marshaling personalizado é inerentemente exclusivo para o objeto que o implementa. Ele usa proxies implementados pelo objeto e fornecidos ao sistema a pedido em tempo de execução. Os objetos que implementam o marshaling personalizado devem implementar o IMarshal interface, enquanto os objetos que suportam o marshaling padrão não.

Se você decidir escrever uma interface personalizada, deverá fornecer suporte a marshaling para ela. Normalmente, poderá fornecer uma DLL de marshalização padrão para a interface que projetar. Você pode criar o código do proxy/stub e a DLL do proxy/stub, ou criar uma biblioteca de tipos que o COM utilizará para realizar o marshaling orientado a dados (usando os dados na biblioteca de tipos).

Para um cliente fazer uma chamada para um método de interface em um objeto em outro processo envolve a cooperação de vários componentes. O proxy padrão é uma parte do código específico da interface que reside no espaço de processo do cliente e prepara os parâmetros da interface para transmissão. Empacota-os, ou serializa-os, de tal forma que podem ser recriados e compreendidos no processo de receção. O stub padrão, também um pedaço de código específico da interface, reside no espaço de processo do servidor e reverte o trabalho do proxy. O stub desempacota, ou desserializa, os parâmetros enviados e encaminha-os para a aplicação do objeto. Ele também empacota informações de resposta para enviar de volta ao cliente.

Componentes da Comunicação Interprocessual

O diagrama a seguir mostra o fluxo de comunicação entre os componentes envolvidos. No lado do cliente do limite do processo, a chamada de método do cliente passa pelo proxy e, em seguida, para o canal, que faz parte da biblioteca COM. O canal envia o buffer que contém os parâmetros empacotados para a biblioteca de tempo de execução RPC, que os transmite através da fronteira do processo. O tempo de execução do RPC e as bibliotecas COM estão presentes em ambos os lados do processo. A distinção entre o canal e o tempo de execução RPC é uma característica desta implementação e não faz parte do modelo de programação ou do modelo conceitual para objetos cliente/servidor COM. Os servidores COM veem apenas o proxy ou stub e, indiretamente, o canal. Implementações futuras podem usar diferentes camadas abaixo do canal ou sem camadas.

Tópicos relacionados

Canal

Inter-Object Comunicação

Microsoft RPC

Proxy

Stub