Erstellen von Eingabe- und Ausgabeadaptern

Dieses Thema enthält die allgemeinen Informationen, die Sie benötigen, um mit der StreamInsight-Plattform Eingabe- und Ausgabeadapter für eine CEP (Complex Event Processing)-Anwendung zu erstellen. Adapter sind Softwaretransformatoren, die Ereignisse an einen StreamInsight-Server oder von diesem übermitteln.

Grundlegendes zu Ereignisfluss und -steuerung

Bei der Erstellung von Adaptern ist es wichtig, den Fluss von Ereignissen durch den StreamInsight-Server sowie die Steuerung dieses Flusses durch die Eingabe- und Ausgabeadapter zu verstehen. Wie in der folgenden Abbildung gezeigt, ist der Fluss der Ereignisse von der Quelle durch die bestehende Abfrage zur Senke unidirektional. Ereignisse werden aus einer Quelle vom Eingabeadapter gelesen, der sie an die Abfrage übermittelt. Die Eingabeereignisse oder neuen Ereignisse, die sich aus der Verarbeitung der Eingabeereignisse ergeben, werden von einem Operator zum nächsten in der Abfrage geschoben. Die Abfrage übermittelt die verarbeiteten Ereignisse an den Ausgabeadapter, der die Ereignisse an die Senke übermittelt. Die Abbildung stellt ein Szenario dar, in dem eine StreamInsight-Abfrage an die beiden Eingabeadapterinstanzen a1 und a2 sowie an die Ausgabeadapterinstanz a4 gebunden wird.

Während der Ereignisfluss von der Quelle zur Senke unidirektional ist, können die Fluss- und Ausführungssteuerung für den Ereignisabruf und die Übertragung an einigen Interaktionspunkten zwischen den Komponenten bidirektional sein. Diese Interaktionspunkte werden in der Abbildung als READ, ENQUEUE, DEQUEUE und WRITE dargestellt.

Die Eingabeadapterimplementierung sollte den READ-Vorgang mit spezifischen Zugriffsmechanismen für das Quellgerät (z. B. eine Datei oder Datenbank) und den ENQUEUE-Vorgang mithilfe der Adapter-APIs ausführen. Ebenso sollte die Ausgabeadapterimplementierung den WRITE-Vorgang mit spezifischen Zugriffsmechanismen für das Senkengerät und den DEQUEUE-Vorgang mithilfe der Adapter-APIs ausführen. Sie müssen den ENQUEUE-Vorgang und den DEQUEUE-Vorgang gemäß einem in einem Diagramm der Adapterstatusübergänge angegebenen Entwurfsmuster implementieren, wie weiter unten in diesem Thema beschrieben.

Bezüglich der Ereignisflusssteuerung können Sie sich Ereignisse als von einem Anbieter an einen Consumer per Push übermittelt (durch Blockpfeile von links nach rechts angegeben) oder als von einem Consumer an einen Anbieter per Pull übermittelt (durch hakenförmige Pfeile angegeben) vorstellen. An den READ- und WRITE-Interaktionspunkten kann die Adapterimplementierung das Push- oder das Pull-Verfahren für die Ereignisflusssteuerung verwenden. Einige der für diese Interaktion zu berücksichtigenden Faktoren sind die Ereignisrate, die von der Quelle oder Senke bereitgestellt werden kann, die Fähigkeit des Adapters zum Einschränken der Quelle oder Senke sowie ggf. Pufferfunktionen, die Sie implementieren können.

Für Quellgeräte, die Ereignisse mit sehr geringer Latenzzeit ausgeben und schwierig einzuschränken sind, wird normalerweise ein Adapter implementiert, in den das Quellgerät Ereignisse per Push übermittelt. Beispiele für solche Geräte sind Sensoren (maschinengesteuerte Ereignisse), Börsenticker und Netzwerkports. Ziehen Sie für Geräte mit höheren Latenzzeiten (Dateien, Datenbanken) eine Implementierung in Betracht, bei der Daten per Pull aus der Quelle in den Adapter übermittelt werden. Ebenso kann auf der Ausgabeseite ein Ausgabeadapter für ein Gerät, das Ereignisse mit sehr hohem Durchsatz akzeptieren kann, für das Übermitteln von Ereignissen per Push in das Gerät implementiert werden. Für langsamere Ausgabegeräte wird möglicherweise eine Vorgehensweise verwendet, bei der das Gerät immer Ereignisse vom Adapter abruft, wenn es Ereignisse nutzen kann.

Der StreamInsight-Server unterstützt am ENQUEUE-Interaktionspunkt ein Pushmodell. Dies bedeutet, dass das Adapterentwurfsmuster es Ihnen ermöglicht, zu einem beliebigen Zeitpunkt so viele Ereignisse wie das Modul nutzen kann in die Warteschlange einzureihen. Der StreamInsight-Server unterstützt am DEQUEUE-Interaktionspunkt ein Pullmodell. Dies bedeutet, dass gemäß dem Adapterentwurfsmuster Ereignisse so schnell wie sie vom Modul bereitgestellt werden können per Pull vom Server übertragen werden müssen.

Daher ist die Einschränkungsrichtlinie für den StreamInsight-Server sehr einfach. Bei einer einfachen Pass-Through-Abfrage ohne blockierende Vorgänge ist die Rate, mit der ein StreamInsight-Server Ereignisse von einem Eingabeadapter am ENQUEUE-Interaktionspunkt nutzen kann, nur durch die Rate eingeschränkt, mit der der Ausgabeadapter Ereignisse vom Server am DEQUEUE-Interaktionspunkt nutzen kann. Der Umfang der vom StreamInsight-Server während der ENQUEUE-Interaktion per Push an den Eingabeadapter übermittelten Daten hängt davon ab, wie schnell die Abfrage die Ausgabe freigeben und wie schnell der Ausgabeadapter diese Ausgabe nutzen kann. StreamInsight bietet einen umfangreichen Satz von Diagnoseansichten, mit denen Sie die Ereignisraten an den einzelnen Interaktionspunkten messen können. Weitere Informationen finden Sie unter Überwachen von StreamInsight-Server und -Abfragen.

Adapterentwicklungstasks

Verwenden Sie die folgende Prüfliste, um den Adapter zu entwickeln.

• Bestimmen Sie den Typ des Adapters (Eingabe oder Ausgabe), den Sie benötigen.

  Ein Eingabeadapter liest die eingehenden Ereignisse in dem Format, in dem sie bereitgestellt werden, und wandelt diese Daten in ein Format um, das vom StreamInsight-Server genutzt werden kann.

  Ein Ausgabeadapter empfängt vom StreamInsight-Server verarbeitete Ereignisse, wandelt die Ereignisse in ein vom Ausgabegerät erwartetes Format um, und gibt die Daten an dieses Gerät aus.

• Bestimmen Sie den Ereignistyp.

  Definieren Sie für einen Eingabeadapter den Ereignistyp, der die Nutzlast von Ereignissen beschreibt, die von der Quelle bereitgestellt werden. Geben Sie für einen Ausgabeadapter den Ereignistyp an, der die Nutzlast von Ereignissen beschreibt, die von der Senke genutzt werden. Weitere Informationen zu Ereignisnutzlasten finden Sie unter StreamInsight-Serverkonzepte.

  Sie geben einen typisierten Adapter für eine Quelle oder Senke an, der immer Ereignisse mit einem festen Nutzlastformat erzeugt oder nutzt, für das die Anzahl und Typen von Feldern im Voraus bekannt sind, und erstellen diesen Adapter. Der Hauptvorteil des typisierten Adapters ist, dass sich das Erstellen von Ereignissen, die in die Warteschlange für den StreamInsight-Server eingereiht werden sollen, relativ einfach implementieren lässt. Da die Feldtypen bereits bekannt sind, können Sie IntelliSense in Visual Studio (oder eine entsprechende Funktion in einer anderen integrierten Entwicklungsumgebung) verwenden, um die Felder aufzufüllen.

  Sie geben einen nicht typisierten Adapter an, wenn die Quelle oder Senke unterschiedliche Nutzlastformate erzeugt oder nutzt, und erstellen diesen. Der Hauptvorteil eines nicht typisierten Adapters ist die Flexibilität, die durch das Angeben des Ereignistyps zum Zeitpunkt der Abfragebindung geboten wird, da die Adapterimplementierung nicht an einen bestimmten Ereignistyp gebunden werden muss. Die Implementierung eines nicht typisierten Adapters ist komplizierter als die Implementierung eines typisierten Adapters. Der nicht typisierte Eingabeadapter muss so geschrieben werden, dass der Typ jedes Felds anhand der während der Abfragebindung bereitgestellten Konfigurationsparameter bestimmt werden kann, dass die Felder einzeln nacheinander aufgefüllt werden und dass dann das Ereignis in die Warteschlange eingereiht wird. Ebenso muss der nicht typisierte Ausgabeadapter in der Lage sein, das Ergebnis der Abfrageverarbeitung von einem aus der Warteschlange entfernten Ereignis auf der Grundlage der Konfigurationsinformationen abzurufen, die bei der Ausgabe bereitgestellt werden.

  Beachten Sie, dass eine Adapterinstanz (typisiert oder nicht typisiert), die an die Abfrage gebunden ist, immer Ereignisse ausgibt, die Nutzlasten eines bestimmten Typs enthalten. Weitere Informationen finden Sie unter Erstellen von Ereignistypen.

• Bestimmen Sie das Ereignismodell.

  Bestimmen Sie das Ereignismodell für die Eingabe- und Ausgabeereignisse. StreamInsight unterstützt drei Ereignismodelle: Point, Interval und Edge. Wenn die Quelle Ereignisse eines festen Ereignismodells bereitstellt, können Sie einen Eingabeadapter für nur dieses Ereignismodell entwerfen. Wenn die Senke Ereignisse eines bestimmten Modells erfordert, können Sie ebenfalls einen Ausgabeadapter für nur dieses Ereignismodell entwerfen. Die meisten Anwendungen benötigen jedoch möglicherweise für einen bestimmten Ereignistyp alle Ereignismodelle. Es wird empfohlen, für jedes Ereignismodell einen typisierten oder nicht typisierten Adapter zu erstellen. Weitere Informationen zu Ereignismodellen finden Sie unter StreamInsight-Serverkonzepte.

  Die Eingabe- und Ausgabe-AdapterFactory-Klassen ermöglichen es Ihnen, diese Adapter zusammen zu verpacken. Der richtige Adapter kann zum Zeitpunkt der Abfragebindung auf Grundlage der Konfigurationsparameter instanziiert werden.

• Wählen Sie die entsprechende Adapterbasisklasse aus.

  Wählen Sie auf der Grundlage des Ereignistyps und -modells die entsprechende Adapterbasisklasse aus. Für die Klassennomenklatur gilt das Muster [Typed][Point | Interval | Edge][Input | Output]. Nicht typisierte Adapter verfügen nicht über das Typed-Präfix.

  Adaptertyp	Eingabeadapter-Basisklasse	Ausgabeadapter-Basisklasse
  Typisierter Point-Adapter	TypedPointInputAdapter	TypedPointOutputAdapter
  Nicht typisierter Point-Adapter	PointInputAdapter	PointOutputAdapter
  Typisierter Interval-Adapter	TypedIntervalInputAdapter	TypedIntervalOutputAdapter
  Nicht typisierter Interval-Adapter	IntervalInputAdapter	IntervalOutputAdapter
  Typisierter Edge-Adapter	TypedEdgeInputAdapter	TypedEdgeOutputAdapter
  Nicht typisierter Edge-Adapter	EdgeInputAdapter	EdgeOutputAdapter

  Weitere Informationen finden Sie unter Microsoft.ComplexEventProcessing.Adapters.

• Entwerfen Sie die Eingabe- und Ausgabe-AdapterFactory-Klasse.

  Eine AdapterFactory ist eine Containerklasse für Adapter. Sie müssen eine Factoryklasse implementieren. Die Basisfactoryklassen sind wie nachfolgend dargestellt organisiert.

  Adaptertyp	Eingabeadapter-Basisklasse	Ausgabeadapter-Basisklasse
  Typisiert	ITypedInputAdapterFactory	ITypedOutputAdapterFactory
  Nicht typisiert	IInputAdapterFactory	IOutputAdapterFactory
  Typisiert mit Stabilitätsunterstützung	IHighWaterMarkTypedInputAdapterFactory	IHighWaterMarkTypedOutputAdapterFactory
  Nicht typisiert mit Stabilitätsunterstützung	IHighWaterMarkInputAdapterFactory	IHighWaterMarkOutputAdapterFactory

  Die Factoryklasse dient den folgenden Zwecken:

  • Sie aktiviert das Freigeben von Ressourcen zwischen verschiedenen Adapterimplementierungen für eine bestimmte Klasse von Geräten (CSV-Datei, SQL Server-Datenbank, allgemeines Protokolldateiformat für Webserver) oder Anwendungsanforderung und ermöglicht die Übergabe von Konfigurationsparametern an den Adapterkonstruktor. Eine Anwendung kann z. B. alle drei Ereignismodelle (Point, Interval und Edge) erfordern. Eine einzelne Factory kann drei Adapterimplementierungen, eine pro Ereignismodell, unterstützen. Ein weiteres Beispiel ist der Fall, dass die Anwendung möglicherweise die gleiche Ereignisquelle hat, z. B. eine Datenbanktabelle, die Quelle jedoch auf der Grundlage der Abfragen, die ausgeführt werden, mehrere Ereignisnutzlaststrukturen aus der gleichen Quelle generiert. In diesem Fall kann eine einzelne Factory Adapterimplementierungen unterstützen, um jede Nutzlaststruktur zu behandeln.

  • Sie stellt für den Adapter ein Gateway zur Serverlaufzeit bereit. Der Adapterentwickler muss die Create()-Methode und die Dispose()-Methode in der Adapterfactory für die Adapterklasse implementieren. Diese Methoden werden während des Startens und Beendens von Abfragen vom Server aufgerufen.

  • Sie stellt für den Adapter ein Gateway zu Vorlaufzeit-Konfigurationsinformationen bereit. Dies ist besonders wichtig für nicht typisierte Adapter, die den Typ jedes Felds in der Struktur anhand von Konfigurationsparametern bestimmen müssen, die während der Abfragebindungszeit bereitgestellt werden. Sie können die Konfigurationsstruktur in der Factoryklasse definieren und diese Konfigurationsstruktur über die Create()-Methode an die Konstruktormethode der Adapterklasse übergeben. Diese Konfigurationsstruktur wird mit DataContractSerialization serialisiert. Von dieser Einschränkung abgesehen bietet Ihnen die Entwicklungsmethodik vollständige Flexibilität beim Auffüllen dieser Konfigurationsstruktur und der Definition ihrer Verwendung im Adapterkonstruktor.

  • Sie ermöglicht, aktuelle Zeitinkremente (CTIs) zu generieren, ohne diese explizit über den Eingabeadapter in die Warteschlange einzureihen. Durch Implementieren der ITypedDeclareAdvanceTimePolicy-Schnittstelle (für eine typisierte Adapterfactory) und der IDeclareAdvanceTimePolicy-Schnittstelle (für eine nicht typisierte Adapterfactory) in der Adapterfactoryklasse kann der Benutzer CTI-Frequenz und -Zeitstempel angeben. Dies vereinfacht den Adaptercode und kann sich auf jeden Ereignisdatenstrom auswirken, den die Factory durch ihre Adapterinstanzen erzeugt. Weitere Informationen finden Sie unter [AdvanceTimeSettingsClass].

  • In stabilen Anwendungen wird Stabilität unterstützt, indem dem Eingabeadapter die Obergrenzenmarkierung für die Wiedergabe verpasster Ereignisse bereitgestellt wird. Außerdem werden dem Ausgabeadapter die Obergrenzenmarkierung und der Offset bereitgestellt, sodass doppelte Ereignisse entfernt werden können. Weitere Informationen finden Sie unter StreamInsight-Stabilität.

• Erstellen und testen Sie den Adapter.

  Kompilieren und entwickeln Sie den Adapter als .NET-Assembly. Testen Sie den Adapter auf grundlegende Vorgänge anhand einer einfachen passthrough-Abfrage, die Ereignisse von einem Eingabeadapter liest und diese ohne eine komplexe Abfrageverarbeitung an den Ausgabeadapter ausgibt. Dadurch wird überprüft, ob der Adapter von Geräten liest und auf diese schreibt und in der Lage ist, Ereignisse in die Warteschlange einzureihen und aus der Warteschlange zu entfernen.

Zustandsautomat des Adapters

Der Zustandsautomat, der die Interaktion zwischen einem Adapter und dem StreamInsight-Server definiert, ist für Eingabe- und Ausgabeadapter identisch. Dies ist wichtig, da der Zustandsautomat Ihnen ein konsistentes Entwicklungsmodell bereitstellt. Der Zustandsautomat wird in der folgenden Abbildung gezeigt.

Die Hauptmerkmale und die Anforderungen für den Zustandsautomaten sind wie folgt:

• Die Start()-Methode und die Resume()-Methode werden vom StreamInsight-Server aufgerufen, und sie müssen von Ihnen als Adapterentwickler implementiert werden. Außerdem müssen Sie die Konstruktormethode für die Adapterklasse und die Dispose()-Methode implementieren, die von der Basisklasse geerbt wird.

• Die Adapterimplementierung muss wiederum die folgenden vom Adapter-SDK bereitgestellten Methoden aufrufen:

  • Enqueue() für den Eingabeadapter. Dies gibt den Wert EnqueueOperationResult.Success oder EnqueueOperationResult.Full zurück.

  • Dequeue() für den Ausgabeadapter. Dies gibt den Wert DequeueOperationResult.Success oder DequeueOperationResult.Empty zurück.

  • Ready(). Dies gibt den booleschen Wert TRUE oder FALSE zurück.

  • Stopped(). Dies gibt den booleschen Wert TRUE oder FALSE zurück.

• Der StreamInsight-Server ruft die interne Methode (als StopQuery() bezeichnet) für den Benutzer asynchron auf, wenn ein Administrator oder Abfrageentwickler die Abfrageausführung über Methoden in der Server-API beendet.

• Aufrufe von Enqueue() und Dequeue() geben den Status Full bzw. Empty zurück, wenn der Adapter einen der folgenden Status aufweist:

  • Angehalten

  • Wird beendet

• Aufrufe von Enqueue() und Dequeue() bewirken, dass eine Ausnahme ausgelöst wird, wenn der Adapter einen der folgenden Status aufweist:

  • Erstellt

  • Beendet

• Aufrufe von Ready() bewirken, dass eine Ausnahme ausgelöst wird, wenn der Adapter in einem der folgenden Status ist:

  • Erstellt

  • Wird ausgeführt

  • Beendet

• Ein Adapter durchläuft einige oder alle der fünf Status (Erstellt, Wird ausgeführt, Angehalten, Wird beendet und Beendet), während er aktiv ist. Ein Statusübergang erfolgt, bevor der StreamInsight-Server Start() oder Resume() aufruft und nachdem der Adapter Enqueue(), Dequeue(), Ready() und Stopped() aufgerufen hat.

• Der StreamInsight-Server und der Adapter nutzen niemals einen Thread gemeinsam. Der Server ruft immer Start() oder Resume() in einem eigenen Arbeitsthread auf. Der Server ruft diesen Thread aus einem Betriebssystemthreadpool für den Adapter ab. Dies bedeutet, dass die Start()-Methode und die Resume()-Methode den Arbeitsthread uneingeschränkt nach Bedarf (z. B. zum Erzeugen von weiteren Threads für asynchrone Lese- oder Schreibvorgänge) verwenden können. Daher müssen Sie bei der Verwendung der Systemressourcen aus diesem Thread mit Vorsicht und bewährten Methoden vorgehen.

• Die API beseitigt die Notwendigkeit der inhärenten Synchronisierung zwischen Start()- und Resume()-Vorgängen (Threads). Der Server ruft immer Resume() auf, nachdem (und nur nachdem) Ready() vom Adapter aufgerufen wurde. Beachten Sie jedoch, dass die Synchronisierung möglicherweise für die dem Gerät zugeordneten Tasks des Lesens, Schreibens oder Pufferns von Ereignissen erforderlich sein kann, besonders in asynchronen E/A-Szenarien. Als bewährte Methode wird empfohlen, nicht blockierende E/A zu verwenden.

• Wenn der Adapter im Leerlauf sein kann, sollte der Adapter den Status in regelmäßigen Abständen überprüfen, um zu ermitteln, ob er zum Beenden seiner Ausführung aufgefordert wurde.

Lebenszyklus der Adapterinteraktion mit dem Server

Der Handshake zwischen dem StreamInsight-Server und dem Adapter ist immer synchron. Daher kann der Adapter zu einem beliebigen Zeitpunkt seiner Ausführung seinen Status überprüfen und entsprechend reagieren. Der Lebenszyklus der Adapterinteraktion mit dem StreamInsight-Server besteht aus den folgenden Vorgängen, die dem in der vorherigen Abbildung gezeigten Zustandsautomaten entsprechen.

• Erstellt

  Eine Adapterinstanz beginnt die Interaktion mit dem StreamInsight-Server, wenn die Abfrage gestartet wird (durch einen entsprechenden Aufruf der StreamInsight-Server-API).

• Wird ausgeführt

  Der Server versetzt den Adapter in den Status "Wird ausgeführt", ruft Start() für den Adapter asynchron auf und garantiert, dass dieser Aufruf nur einmal ausgeführt wird. Wenn der Adapter den Status "Wird ausgeführt" aufweist, kann er Ereignisse in die Warteschlange für den Server einreihen oder aus dieser entfernen.

  Im Idealfall weist der Adapter meistens den Status "Wird ausgeführt" auf. Das empfohlene Entwurfsmuster ist, die Leser- oder Schreiberroutine aus der Start()-Methode aufzurufen, vorzugsweise in einem eigenen Thread, und die Start()-Routine zu beenden, sodass der Arbeitsthread schnell aufgegeben wird.

  Die Leserroutine (deren Name beispielsweise ProduceEvents() lauten kann) liest Ereignisse aus der Quelle und ruft Enqueue() auf, um Ereignisse per Push an den Server zu übermitteln. Im Fall eines Ausgabeadapters ruft eine Schreiberroutine (deren Name beispielsweise ConsumeEvents() lauten kann) Dequeue() auf, um Ereignisse per Pull vom Server zu übertragen und in die Senke zu schreiben.

• Angehalten

  Wenn der Server kein Ereignis aus der Warteschlange empfangen kann oder kein Ereignis ausgeben kann, um es aus der Warteschlange zu entfernen, wird der Eingabe-oder Ausgabeadapter in den Status "Angehalten" versetzt. Dies verursacht den Aufruf von Enqueue() und Dequeue(), um den Status FULL bzw. EMPTY zurückzugeben. Im Status "Angehalten" können Sie Verwaltungsvorgänge implementieren, z. B. das Speichern der Position des letzten gelesenen Datensatzes aus der Datenbank oder der letzten gelesenen Zeile aus der Datei. Am Ende dieses optionalen Abschnitts müssen Sie die Ready()-Methode aufrufen, um dem Server mitzuteilen, dass die Ausführung des Adapters fortgesetzt werden kann. Wenn die Routine im gleichen Arbeitsthread wie Start() selbst ausgeführt wird, muss die Start()-Routine selbst beendet werden.

• Als Reaktion auf einen Ready()-Aufruf stellt der Server den Status "Wird ausgeführt" des Adapters wieder her und ruft immer Resume() asynchron in einem anderen Arbeitsthread auf. Sie können im Entwurf festlegen, dass mit Resume() die letzte fehlgeschlagene Iteration in die Warteschlange eingereiht oder aus der Warteschlange entfernt wird und dann ProduceEvents() oder ConsumeEvents() aufgerufen wird. Dieses Muster kann solange wiederholt werden, bis der Adapter in den Status "Beendet" oder "Wird beendet" wechselt.

• Wird beendet

  Der Server kann zu einem beliebigen Zeitpunkt im Status "Wird ausgeführt" oder "Angehalten" als Reaktion auf eine asynchrone Anforderung zum Beenden der Abfrage den Adapter in den Status "Wird beendet" versetzen. In diesem Status wird durch den Aufruf von Enqueue() oder Dequeue() ebenfalls der Status FULL bzw. EMPTY zurückgegeben.

  Der Status "Wird beendet" stellt für die Adapterimplementierung einen Stagingbereich bereit, damit das Beenden des Adapters ordnungsgemäß vorbereitet werden kann. Sie können den Adapter so implementieren, dass alle Ressourcen, die er abgerufen hat (Threads, Arbeitsspeicher), aufgegeben werden und dann die Stopped()-Methode aufgerufen wird. Der Server beendet die Ausführung des Adapters erst, wenn diese Methode aufgerufen wird.

  Beachten Sie, dass der Adapter möglicherweise asynchron in den Status "Wird beendet" versetzt wird. Der Adapter benötigt möglicherweise ein Verfahren, um zu erkennen, dass er sich im Status "Wird beendet" befindet. Wie bereits erläutert, ruft der Adapter gemäß dem Entwurfsmuster Ready() auf, wenn er angehalten wurde. Als Reaktion ruft der Server eine weiteres Mal die Resume()-Methode auf und ermöglicht hierdurch die Erkennung des Status "Wird beendet" in der Resume()-Methode. Als bewährte Methode wird empfohlen, die Überprüfung auf den Status "Wird beendet" als ersten Codeblock in der Implementierung von Start() und Resume() zu positionieren.

• Beendet

  Der Adaptercode kann Stopped() an jedem Punkt aufrufen. Dies versetzt den Adapter in den Status "Beendet". Als Entwurfsvorgehensweise wird empfohlen, dass die Ressourcen bereinigt werden, die der Adapter abgerufen hat, bevor Stopped() aufgerufen wird.

  Wichtig
  Wenn die Stopped()-Methode nicht aufgerufen wird, bleibt die letzte Speicherseite, die der Abfrage zugeordnet ist, reserviert. Dies kann geringe Speicherverluste verursachen, die sich im Zeitverlauf summieren können, wenn ein Prozess viele Start- und Stoppzyklen für Abfragen aufweist.

  Im Status "Beendet" kann der Adapter nicht auf für den StreamInsight-Server spezifische Konstrukte oder Ereignisarbeitsspeicher verweisen oder Elemente in die Warteschlange einreihen bzw. aus dieser entfernen. Diese Aktionen lösen eine Ausnahme aus. Das Betriebssystem und geräteseitige Bereinigungsaktivitäten können jedoch fortgesetzt werden.

Beispiele

Beispiele für eine Vielzahl von Eingabe- und Ausgabeadaptern sowie Eingabe- und Ausgabeadapterfactorys finden Sie in den Beispielen unter StreamInsight-Beispiele.

Siehe auch

Konzepte

StreamInsight-Serverkonzepte

StreamInsight-Serverarchitektur