Der LightweightClient-Side Handler
Mit einfachen clientseitigen Handlern können Sie allgemeine clientseitige Handler beliebiger Größe erstellen, um Sie bei jeder Art von Standardaufgabe zu unterstützen. Als Handler können diese von mehr als einem Client verwendet werden. Sie unterscheiden sich von OLE-Handlern, da sie nicht erstellt werden können, bevor der Server gestartet wird, und ihre Lebensdauer an die des Proxy-Managers gebunden ist, wodurch eine mögliche Racebedingung verhindert wird, in der der Handler andernfalls vorzeitig freigegeben werden könnte.
Der Proxy-Manager ist das vom System erstellte Objekt, das die IMarshal-Schnittstelle implementiert. Wenn Sie Standardmarshalling verwenden, erstellt das System es für Sie, wenn Sie CoGetStandardMarshal (oder CoGetStdMarshalExzum Erstellen eines aggregierten Marshallers für einfache Handler) aufrufen, und implementiert außerdem die Schnittstellen IClientSecurity und IMultiQI für das Objekt. Auf Serverseite gibt es ein entsprechendes Systemobjekt, das auch IMarshal implementiert. Diese Objekte verarbeiten das Marshalling für Sie transparent.
Es gibt zwei allgemeine Typen dieser Handler, die Sie möglicherweise implementieren möchten:
- Ein Handler, der einen Dienst ausführt, für den keine zusätzlichen Daten vom Server erforderlich sind
- Ein Handler, der zusätzliche Daten vom Server verwendet
Einige mögliche Verwendungsmöglichkeiten der zusätzlichen Daten im vom Server bereitgestellten Stream sind:
- Statische Daten vom Server. Unabhängig von der bestimmten Schnittstelle, die gemarshallt wird, schreibt der Server dieselben Daten in den Stream.
- Schnittstellenspezifische Daten vom Server. Je nachdem, welche bestimmte Schnittstelle gemarshallt wird, kann der Server unterschiedliche Daten in den Stream schreiben.
- Schnittstellenspezifische Hilfser. Schnittstellenspezifische COM-Komponenten, die im Clienthandler aggregiert und an den Standardproxy delegiert werden. Um beispielsweise die Netzwerkleistung zu verbessern, könnte eine COM-Komponente für IStream das clientseitige Zwischenspeichern von Daten, Read-Ahead, Write-Behind, Op-Locking usw. verwenden.
- Netzwerkversion einer Schnittstelle. Die Netzwerkversion der Schnittstelle ist anders als die Schnittstelle, die vom Client- und Serveranwendungscode verfügbar gemacht wird. Es ist z. B. möglich, die verfügbar gemachten Schnittstellen IA und IB über dieselbe Netzwerkschnittstelle INetAB zu multiplexen, wie es der Einbettungsserverhandler tut. Beispielsweise könnte eine Datenübertragungsschnittstelle in eine Netzwerkschnittstelle konvertiert werden, die Pipes für eine effiziente Datenübertragung verwendet.
Downlevelclients verfügen möglicherweise aus zwei Gründen nicht über die Möglichkeit, das Unmarshaling von Schnittstellen mit benutzerdefinierten Handlern zu entpacken: Erstens können sie die clSID, die im benutzerdefinierten gemarshallten Paket verwendet wird, nicht verstehen, wenn der Serverhandler aggregiert wird und das Objekt einen Handler möchte. Zweitens wird der Handlercode möglicherweise nicht einmal auf clientseitiger Seite ausgeführt, wenn neue Funktionen von COM erforderlich sind, um den aggregierten Standard-Marshaller zu erstellen und QueryInterface-Remoteaufrufe auszuführen.