Kontextaktivierung

In COM+ wird jedes COM-Objekt mit einem zugeordneten Kontext erstellt. Dies bedeutet, dass entweder ein neuer Kontext erstellt und initialisiert werden muss oder ein entsprechender vorhandener Kontext verwendet wird. Dieser Prozess wird als Aktivierung bezeichnet. In COM+ wird ein Objekt entweder in seinem eigenen Kontext oder in dem seines Erstellers aktiviert (ein Objekt, das die Aktivierung des Objekts angefordert hat, z. B. durch Aufrufen von CoCreateInstance).

Unter bestimmten Umständen, z. B. beim Objektpooling, wird ein Objekt aktiviert, ohne von Grund auf neu erstellt zu werden. In diesem Fall wird eine ausgeführte instance in einem Kontext aktiviert. Im Laufe seiner Lebensdauer kann es in verschiedenen Kontexten wiederholt aktiviert werden.

Der grundlegende Mechanismus ist in beiden Fällen identisch: Ein Objekt ist einem Kontext zugeordnet, und dieser Kontext wird ordnungsgemäß initialisiert, um die Laufzeitanforderungen des Objekts darzustellen.

Fluss von Kontexteigenschaften

Wenn ein Objekt als Reaktion auf eine Erstellungsanforderung eines anderen Objekts aktiviert wird, muss COM+ zwischen ihnen vermitteln, um das downstream-Objekt ordnungsgemäß zu aktivieren. COM+ muss den Kontext des Aufrufers mit der Konfiguration der aufgerufenen Komponente vergleichen und dann entscheiden, wo die downstream-Komponente aktiviert werden soll und wie die Kontexteigenschaften initialisiert werden.

Um die Konfiguration der Komponente zu ermitteln, sucht COM+ sie in der COM+-Klassenregistrierungsdatenbank, die für extrem schnelle Laufzeitsuchen optimiert ist. (Dies hängt davon ab, wie Sie eine Komponente bei der Installation in einer COM+-Anwendung konfiguriert haben.) Die Konfiguration der Komponente wird dann anhand des Zustands der Kontexteigenschaften des Aufrufers untersucht.

In einigen Fällen ist die Konfiguration mit dem Kontext des Aufrufers konsistent, und die Komponente kann innerhalb des Kontexts des Aufrufers aktiviert werden. Dies kann nur geschehen, wenn der Kontext des Aufrufers alle Laufzeitanforderungen des neuen Objekts erfüllt.

Wenn die downstream-Komponente nicht innerhalb des Kontexts des Aufrufers aktiviert werden kann, wird sie in einem eigenen Kontext in einem entsprechenden Apartment aktiviert. In diesem Fall können bestimmte Kontexteigenschaften vom Aufrufer zum Aufgerufenen fließen. Wenn der Aufrufer beispielsweise einer Transaktion zugeordnet ist und der Aufgerufene Transaktionen unterstützt, erhält das neue Objekt seinen eigenen Kontext (für die Abstimmung in der Transaktion benötigt es ein eigenes konsistentes Flag) und erbt die Transaktions-ID und Aktivitäts-ID des Aufrufers (die sich in derselben Transaktions- und Synchronisierungsdomäne befinden).

Ignorierte Kontexteigenschaften

Je nachdem, wie eine Komponente konfiguriert ist, spielen einige Kontexteigenschaften möglicherweise keine Rolle bei der Bestimmung, ob sie im Kontext des Erstellers oder in einem eigenen Kontext aktiviert wird. Beispielsweise spielen die Einstellungen Transaktionen deaktiviert und Synchronisierung deaktiviert, die das Vorhandensein einer Transaktion oder einer Synchronisierungsdomäne angeben, bei der Aktivierung der Komponente überhaupt keine Rolle. Diese Eigenschaften werden grundsätzlich ignoriert, wenn der Kontext fließt. Wenn eine Komponente nur die Zugriffsüberprüfung auf Prozessebene verwendet, wird ihre Sicherheitskontexteigenschaft ignoriert. Die Sicherheitskonfiguration der Komponente spielt bei der Aktivierung nie eine Rolle.

Erzwingen der Aktivierung im Kontext des Aufrufers

Unter bestimmten Umständen möchten Sie möglicherweise, dass ein Objekt nur im Kontext des Aufrufers aktiviert wird, d. h. niemals in seinem eigenen Kontext aktiviert wird. Sie können z. B. das Verhalten des Objekts steuern, wenn es über eine Kontextgrenze hinweg aufgerufen wird.

Sie können sicherstellen, dass ein Objekt nicht in seinem eigenen Kontext aktiviert werden kann, indem Sie auf der Seite Eigenschaften der Komponente auf der Registerkarte Aktivierung die Option Muss in Aufrufern aktiviert werden auswählen, indem Sie das Verwaltungstool Komponentendienste verwenden. (Schritt-für-Schritt-Anweisungen finden Sie unter Erzwingen der Aktivierung im Kontext des Aufrufers .) Wenn Sie diese Option auswählen, schlägt CoCreateInstance fehl, wenn das Objekt im Kontext des Aufrufers nicht aktiviert werden kann, wodurch CO_E_ATTEMPT_TO_CREATE_OUTSIDE_CLIENT_CONTEXT zurückgegeben wird.

Standardkontext

Standardkontexte unterstützen nicht konfigurierte Komponenten, d. h. COM-Komponenten, die nicht in COM+-Anwendungen installiert und nicht in der COM+-Klassenregistrierungsdatenbank registriert sind. Wenn nicht konfigurierte Komponenten über ein kompatibles Threadingmodell verfügen, werden sie im Kontext des Aufrufers aktiviert. Andernfalls werden sie in einem Standardkontext in der entsprechenden Wohnung aktiviert. Jedes Apartment verfügt über einen Standardkontext zur Unterstützung von COM-Objekten, die keine COM+-Dienste verwenden.

Hooking-Aktivierung

Durch die Implementierung von IObjectControl::Activate und IObjectControl::D eactivate können Sie aktivierung und deaktivieren, um eine spezielle Initialisierung im neuen Kontext durchzuführen. Diese Methoden werden von COM+ an bestimmten Punkten im Lebenszyklus eines Objekts aufgerufen, wenn das Objekt für die Verwendung von JIT-Aktivierung oder Objektpooling konfiguriert ist. Weitere Informationen finden Sie unter COM+ Just-in-Time-Aktivierung und COM+-Objektpooling .

Abfangen kontextübergreifender Aufrufe