call_as (attributo)

Articolo
06/13/2023

L'attributo [call_as] consente di eseguire il mapping di una funzione che non può essere chiamata in remoto a una funzione remota.

[call_as (local-proc), [ , operation-attribute-list ] ] operation-name ;

Parametri

local-proc: Specifica una routine definita dall'operazione.
operation-attribute-list: Specifica uno o più attributi che si applicano all'operazione. Separare più attributi con virgole.
nome operazione: Specifica l'operazione denominata presentata all'applicazione.

Commenti

La possibilità di eseguire il mapping di una funzione che non può essere chiamata in remoto a una funzione remota è particolarmente utile nelle interfacce con numerosi tipi di parametri che non possono essere trasmessi in rete. Anziché usare molti tipi [represent_as] e [transmit_as], è possibile combinare tutte le conversioni usando le routine [call_as]. Vengono fornite le due routine [call_as] (lato client e lato server) per associare la routine tra le chiamate dell'applicazione e le chiamate remote.

L'attributo [call_as] può essere usato per le interfacce degli oggetti. In questo caso, la definizione dell'interfaccia può essere usata per le chiamate locali e le chiamate remote perché [call_as] consente l'accesso a un'interfaccia a cui non è possibile accedere in remoto per eseguire il mapping trasparente a un'interfaccia remota. Impossibile usare l'attributo [call_as] con la modalità /osf .

Si supponga, ad esempio, che la routine f1 nell'interfaccia dell'oggetto IFace richieda numerose conversioni tra le chiamate utente e ciò che viene effettivamente trasmesso. Gli esempi seguenti descrivono i file IDL e ACF per interfaccia IFace:

Nel file IDL per interfaccia IFace:

[local] HRESULT f1 ( <users parameter list> ) 
[call_as( f1 )] long Remf1( <remote parameter list> );

In ACF per interfaccia IFace:

[call_as( f1 )] Remf1();

In questo modo il file di intestazione generato definisce l'interfaccia usando la definizione di f1, ma fornisce anche stub per Remf1.

Il compilatore MIDL genererà la Vtable seguente nel file di intestazione per interfaccia IFace:

struct IFace_vtable
{ 
    HRESULT ( * f1) ( <users parameter list> ); 
    /* Other vtable functions. */
};

Il proxy lato client avrà quindi un tipico proxy generato da MIDL per Remf1, mentre lo stub lato server per Remf1 sarà lo stesso del tipico stub generato da MIDL:

HRESULT IFace_Remf1_Stub ( <parameter list> ) 
{ 
    // Other function code.

    /* instead of IFace_f1 */
    invoke IFace_f1_Stub ( <remote parameter list> ); 

    // Other function code.
}

Quindi, le due routine di associazione [call_as] (lato client e lato server) devono essere codificate manualmente:

HRESULT f1_Proxy ( <users parameter list> ) 
{ 
    // Other function code.

    Remf1_Proxy ( <remote parameter list> ); 

    // Other function code.
} 
 
long IFace_f1_Stub ( <remote parameter list> ) 
{ 
    // Other function code.

    IFace_f1 ( <users parameter list> ); 

    // Other function code.
    }

Per le interfacce a oggetti, questi sono i prototipi per le routine di legame.

Per il lato client:

<local_return_type>  <interface>_<local_routine>_proxy( 
    <local_parameter_list> );

Per il lato server:

<remote_return_type>  <interface>_<local_routine>_stub(
    <remote_parameter_list> );

Per le interfacce non oggetti, questi sono i prototipi per le routine di legame.