Share via


Dettagli del marshalling

Se si usa il marshalling standard, COM gestisce tutti i dettagli descritti qui. Tuttavia, ci sono pochi programmatori che necessitano di questi dettagli e per coloro che sono interessati alle informazioni sottostanti. Il marshalling è il processo di creazione di pacchetti e di decomprimere i parametri in modo che possa essere eseguita una chiamata di procedura remota.

Il marshalling di tipi di parametri diversi viene sottoposto a marshalling in modi diversi. Ad esempio, il marshalling di un parametro integer comporta semplicemente la copia del valore nel buffer dei messaggi. Anche se in questo caso semplice, esistono problemi come l'ordinamento dei byte per gestire le chiamate tra computer. Il marshalling di una matrice, tuttavia, è un processo più complesso. I membri della matrice vengono copiati in un ordine specifico in modo che l'altro lato possa ricostruire esattamente la matrice. Quando viene eseguito il marshalling di un puntatore, i dati a cui punta il puntatore vengono copiati seguendo le regole e le convenzioni per gestire i puntatori annidati nelle strutture. Esistono funzioni univoce per gestire il marshalling di ogni tipo di parametro.

Con il marshalling standard, i proxy e gli stub sono risorse a livello di sistema per l'interfaccia e interagiscono con il canale tramite un protocollo standard. Il marshalling standard può essere usato sia dalle interfacce standard definite da COM che dalle interfacce personalizzate, come indicato di seguito:

  • Nel caso della maggior parte delle interfacce COM, i proxy e gli stub per il marshalling standard sono oggetti componenti in-process caricati da una DLL a livello di sistema fornita da COM in Ole32.dll.
  • Nel caso di interfacce personalizzate, i proxy e gli stub per il marshalling standard vengono generati dalla finestra di progettazione dell'interfaccia, in genere con MIDL. Questi proxy e stub sono configurati staticamente nel Registro di sistema, in modo che qualsiasi potenziale client possa usare l'interfaccia personalizzata attraverso i limiti del processo. Questi proxy e stub vengono caricati da una DLL che si trova tramite il Registro di sistema, usando l'ID interfaccia (IID) per l'interfaccia personalizzata di cui esegue il marshalling.
  • Un'alternativa all'uso di MIDL per generare proxy e stub per interfacce personalizzate, è possibile generare invece una libreria dei tipi e il motore di marshalling basato sulla libreria dei tipi eseguirà il marshalling dell'interfaccia.

In alternativa al marshalling standard, un'interfaccia (standard o personalizzata) può usare il marshalling personalizzato. Con il marshalling personalizzato, un oggetto implementa dinamicamente i proxy in fase di esecuzione per ogni interfaccia supportata. Per qualsiasi interfaccia specifica, l'oggetto può selezionare il marshalling standard fornito da COM o il marshalling personalizzato. Questa scelta viene effettuata dall'oggetto in base all'interfaccia. Una volta effettuata la scelta per una determinata interfaccia, rimane attiva durante la durata dell'oggetto. Tuttavia, un'interfaccia di un oggetto può usare il marshalling personalizzato mentre un altro usa il marshalling standard.

Il marshalling personalizzato è intrinsecamente univoco per l'oggetto che lo implementa. Usa proxy implementati dall'oggetto e forniti al sistema su richiesta in fase di esecuzione. Gli oggetti che implementano il marshalling personalizzato devono implementare l'interfaccia IMarshal , mentre gli oggetti che supportano il marshalling standard non lo fanno.

Se si decide di scrivere un'interfaccia personalizzata, è necessario fornire supporto per il marshalling. In genere, si fornirà una DLL di marshalling standard per l'interfaccia progettata. È possibile creare il codice proxy/stub e la DLL proxy/stub oppure creare una libreria dei tipi che COM userà per eseguire il marshalling basato sui dati (usando i dati nella libreria dei tipi).

Affinché un client eselabori una chiamata a un metodo di interfaccia in un oggetto in un altro processo, comporta la cooperazione di diversi componenti. Il proxy standard è una parte di codice specifico dell'interfaccia che risiede nello spazio di elaborazione del client e prepara i parametri dell'interfaccia per la trasmissione. Pacchetti, o marshalling, in modo che possano essere ricreati e compresi nel processo di ricezione. Lo stub standard, anche un frammento di codice specifico dell'interfaccia, risiede nello spazio di elaborazione del server e inverte il lavoro del proxy. Lo stub unpackages o unmarshals, i parametri inviati e li inoltra all'applicazione oggetto. Include anche informazioni di risposta da inviare al client.

Nota

I lettori hanno familiarità con RPC rispetto a COM possono essere usati per visualizzare i termini stub client e stub del server. Questi termini sono analoghi a proxy e stub.

 

Componenti delle comunicazioni interprocesso

Il diagramma seguente illustra il flusso di comunicazione tra i componenti coinvolti. Sul lato client del limite del processo, la chiamata al metodo del client passa attraverso il proxy e quindi sul canale, che fa parte della libreria COM. Il canale invia il buffer contenente i parametri di marshalling alla libreria di runtime RPC, che la trasmette attraverso il limite del processo. Il tempo di esecuzione RPC e le librerie COM esistono su entrambi i lati del processo. La distinzione tra il canale e il runtime RPC è una caratteristica di questa implementazione e non fa parte del modello di programmazione o del modello concettuale per gli oggetti client/server COM. I server COM visualizzano solo il proxy o lo stub e, indirettamente, il canale. Le implementazioni future possono usare livelli diversi sotto il canale o nessun livello.

Diagram that shows the Client.exe and Server.exe flows on each side fo the Process Boundary.

Canale

Comunicazione tra oggetti

Microsoft RPC

Proxy

Stub