Freigeben über


Übergeben von Objekten als Parameter

Der COM+-Komponentendienst aktiviert nicht die Queuing für jede vorhandene COM-Komponente. Es gibt Einschränkungen für die Arten von Methoden, die in die Warteschlange gestellt werden können. Aufgrund von Messagingeinschränkungen müssen Methoden die folgenden Regeln einhalten:

  • Sie müssen nur Eingabeparameter enthalten.
  • Sie müssen kein anwendungsspezifisches Ergebnis zurückgeben.

Darüber hinaus gibt es Einschränkungen für die Typen von Eingabeparametern, die an eine Warteschlangekomponente übergeben werden können. Zur Laufzeit packt der Inwarteschlangenkomponentendienst die Argumente am Client und übergibt sie mithilfe von Message Queuing an die Serverkomponente. Einfache Typen, z. B. ganze Zahlen und Booleanen, können leicht gemarschiert werden – komplexere Typen können ohne Hilfe nicht gemarschelt werden.

Bei der Übergabe eines Objekts über den Methodenaufruf einer Warteschlange als Parameter übergibt der Client das Objekt an die Aufzeichnung. Der Aufzeichnungsrecorder marschiert das Objekt in eine Message Queuing-Nachricht und übergibt es an den Listener. Nachdem der Listener die Nachricht aufgenommen und an den Spieler übergeben hat, muss der Spieler das Objekt erneut angeben, um es an den vom Client angegebenen Methodenaufruf zu senden. Basierend auf den Lebensdauern des Clients und servers in einer in eine Warteschlange gestellten Umgebung muss die Auswirkung darauf basieren, dass diese Objekte in der Lage sein müssen, nach Wert zu marshallen. Da COM+ keine Pass-by-Wert-Semantik für Standard-COM-Objekte bereitstellt, benötigt der Recorder und Spieler Hilfe von der Komponente, um das Objekt zu marshal und unmarshalieren.

Objektverweise, die IPersistStream unterstützen, können als Parameter verwendet werden, um Aufrufe in der Warteschlange zu verwenden. Das Objekt kann keine Annahmen darüber treffen, wann es wieder erstellt wird. Der Server kann beispielsweise nicht verfügbar sein, oder die Serverkomponente kann erst später am Tag gestartet werden. Objekte, die IPersistStream nicht unterstützen, geben einen Fehler zurück.

Visual Basic persistente Objekte

Microsoft Visual Basic 6 ermöglicht das Erstellen von dauerhaften Objekten. Diese Objekte unterstützen IPersistStream und können als Parameter an Inwarteschlangen-Komponentenmethodenaufrufe übergeben werden. Bevor ein Visual Basic -Objekt an eine Warteschlange übergeben werden kann, muss das persistente Objekt initialisiert werden. Dies kann auf eine der folgenden beiden Arten erfolgen:

  • Wenn die Anwendung, die das persistente Objekt erstellt, in Visual Basic geschrieben wird, verarbeitet die Visual Basic Laufzeit die Objektinitialisierung automatisch.
  • Wenn die Anwendung, die das Visual Basic dauerhaften Objekt erstellt, in einer anderen Sprache als Visual Basic geschrieben wird, z. B. Microsoft Visual C++, muss die Anwendung die Komponente explizit initialisieren, indem sie entweder die IPersistStream-Schnittstelle des dauerhaften Objekts abfragen oder die IPersistStreamInit::InitNew aufrufen oder IPersistStream::Load-Methode.

ADO-Recordsets und OLE DB-Rowsets

Durch das Übergeben von ADO Recordset - oder OLE DB-Rowsetobjekten zwischen Komponenten kann eine Komponente die Ergebnisse von Abfragen verarbeiten, die von einer anderen Komponente ausgeführt werden. Dies ist hilfreich beim Bereitstellen einer Anwendung auf mehreren Computern. Recordset - und Rowset-Objekte können als Methodenparameter an warteschlangede Komponenten mit den folgenden Einschränkungen übergeben werden:

  • Serverseitige Recordset-Objekte können nicht mithilfe von IPersistStream gemarschiert werden. Nur clientseitige Recordset-Objekte können als Parameter an einen Aufruf der Warteschlange-Komponentenmethode übergeben werden.
  • Wenn Sie direkt mit OLE DB arbeiten, muss das OLE DB-Rowset als clientseitiges Rowset definiert werden.