Aufruf als Attribut

Mit dem Attribut [call_as] können Sie eine Funktion zuordnen, die nicht remote aufgerufen werden kann, einer Remotefunktion.

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

Parameter

local-proc

Gibt eine vorgangsdefinierte Routine an.

operation-attribute-list

Gibt mindestens ein Attribut an, das für den Vorgang gilt. Trennen Sie mehrere Attribute durch Kommas.

Vorgangsname

Gibt den benannten Vorgang an, der der Anwendung angezeigt wird.

Bemerkungen

Die Möglichkeit, eine Funktion, die nicht remote aufgerufen werden kann, einer Remotefunktion zuzuordnen, ist besonders hilfreich bei Schnittstellen mit zahlreichen Parametertypen, die nicht über das Netzwerk übertragen werden können. Anstatt viele [represent_as] und [transmit_as] Typen zu verwenden, können Sie alle Konvertierungen mithilfe von [call_as] Routinen kombinieren. Sie stellen die beiden [call_as] Routinen (Client- und Serverseite) bereit, um die Routine zwischen den Anwendungsaufrufen und den Remoteaufrufen zu binden.

Das Attribut [call_as] kann für Objektschnittstellen verwendet werden. In diesem Fall kann die Schnittstellendefinition sowohl für lokale Aufrufe als auch für Remoteaufrufe verwendet werden, da [call_as] ermöglicht, dass eine Schnittstelle, auf die nicht remote zugegriffen werden kann, transparent einer Remoteschnittstelle zugeordnet werden kann. Das [call_as] -Attribut kann nicht mit dem /osf-Modus verwendet werden.

Angenommen, die Routine f1 in der Objektschnittstelle IFace erfordert zahlreiche Konvertierungen zwischen den Benutzeraufrufen und dem, was tatsächlich übertragen wird. In den folgenden Beispielen werden die IDL- und ACF-Dateien für die IFace-Schnittstelle beschrieben:

In der IDL-Datei für die Schnittstelle IFace:

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

In der ACF für die Schnittstelle IFace:

[call_as( f1 )] Remf1();

Dadurch definiert die generierte Headerdatei die Schnittstelle mithilfe der Definition von f1, stellt aber auch Stubs für Remf1 bereit.

Der MIDL-Compiler generiert die folgende Vtable in der Headerdatei für die IFace-Schnittstelle:

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

Der clientseitige Proxy verfügt dann über einen typischen MIDL-generierten Proxy für Remf1, während der serverseitige Stub für Remf1 mit dem typischen MIDL-generierten Stub identisch ist:

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

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

    // Other function code.
}

Anschließend müssen die beiden [call_as] Bondroutinen (Client- und Serverseite) manuell codiert werden:

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.
    }

Für Objektschnittstellen sind dies die Prototypen für die Bondroutinen.

Clientseitig:

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

Serverseitig:

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

Für Nichtobjektschnittstellen sind dies die Prototypen für die Bondroutinen.

Clientseitig:

<local_return_type>  <local_routine> ( <local_parameter_list> );

Serverseitig:

<local_return_type>  <interface>_v<maj>_<min>_<local_routine> ( 
    <remote_parameter_list> );

Siehe auch

/Osf

represent_as

transmit_as