Lebenszyklus von benutzerdefinierten Input-Knoten in Java

Ein benutzerdefinierter Input-Knoten, der in der Programmiersprache Java geschrieben wurde, durchläuft während seines Lebenszyklus verschiedene Phasen.

Folgende Phasen werden im Lebenszyklus durchlaufen:

Registrierung

In der Registrierungsphase macht sich ein in Java geschriebener benutzerdefinierter Input-Knoten dem Broker bekannt. Der Knoten wird beim Broker über die statische Methode getNodeName registriert. Immer, wenn ein Broker startet, lädt er alle relevanten Java-Klassen. An diesem Punkt wird die statische Methode getNodeName aufgerufen, und der Broker registriert den Input-Knoten unter dem in der Methode getNodeName angegebenen Knotennamen. Wenn Sie keinen Knotennamen angeben, erzeugt der Broker automatisch einen Namen für den Knoten, ausgehend vom Paket, in dem er enthalten ist.

Die Verwendung einer statischen Methode an dieser Stelle bedeutet, dass diese vom Broker aufgerufen werden kann, bevor eine Instanz des Knotens erstellt wird.

Instanzerstellung

Die Instanzerstellung eines mit Java erstellten benutzerdefinierten Empfangsknotens erfolgt, wenn der Broker einen Nachrichtenfluss implementiert, der diesen benutzerdefinierten Empfangsknoten enthält. Nach Erstellen der Knoteninstanz wird der Konstruktor der Klasse des Input-Knotens durch den Broker aufgerufen.

Wenn ein Knoten instanziert wird und Sie irgendwelche Terminals spezifiziert haben, werden diese erzeugt. Ein Nachrichtenverarbeitungsknoten kann über beliebig viele Ein- und Ausgabeterminals verfügen. Sie müssen die Methoden createInputTerminal und createOutputTerminal in ihren Knoten-Konstruktor aufnehmen, um diese Terminals zu deklarieren.

Wenn die Ausnahmen, die an den Input-Knoten zurückgegeben werden, verarbeitet werden sollen, erstellen Sie mithilfe von createOutputTerminal ein Catch-Terminal für den Input-Knoten. Wenn dann vom Input-Knoten ein Fehler abgefangen wird, wird dieser vom Catch-Terminal in derselben Weise verarbeitet wie von einem MQInput-Knoten. Sie können die meisten Ausnahmen an den Broker zurückgehen lassen, wie etwa Ausnahmen durch Probleme bei der Implementierung des Knotens. Der Broker wird den Benutzer bei eventuellen Konfigurationsfehlern warnen.

Als Minimum reicht es aus, wenn Ihre Konstruktorklasse diese Ausgabeterminals an Ihrem Input-Knoten erzeugt. Sollte jedoch die Initialisierung von Attributwerten, erforderlich sein, z. B. für die Definition eines Parsers für die erste Syntaxanalyse des Knotens, der vom Input-Knoten übergeben wird, sollte der entsprechende Code an dieser Stelle des Input-Knotens eingefügt werden.

Verarbeitung

Die Nachrichtenverarbeitung für einen Input-Knoten beginnt beim Aufruf der Methode run durch den Broker. Die Methode run erstellt die Eingabenachricht und sollte die Verarbeitungsfunktion für den Input-Knoten enthalten.

Die Definition der Methode run erfolgt über MbInputNodeInterface, also die Schnittstelle eines benutzerdefinierten Knotens, die diesen erst als Input-Knoten definiert. Der Knoten muss die Methode run enthalten. Beinhaltet der benutzerdefinierte Input-Knoten nicht die Methode run, kann der Quellcode des Knotens nicht kompiliert werden.

Wird ein Nachrichtenfluss mit einem benutzerdefinierten Input-Knoten erfolgreich implementiert, ruft der Broker die Implementierungsmethode 'run' des Knotens auf; dies erfolgt so lange, bis die Nachrichtenverarbeitung beginnt.

Wenn ein Nachrichtenfluss startet, wird vom Broker ein einzelner Thread abgefertigt und in die run-Methode des Input-Knotens aufgerufen. Wenn die MethodedispatchThread() aufgerufen wird, können noch weitere Threads in derselben run-Methode erzeugt werden. Diese neuen Threads werden umgehend in der run-Methode des Input-Knotens aufgerufen und können genau auf dieselbe Weise wie der ursprüngliche Thread gehandhabt werden. Die Anzahl erzeugbarer neuer Threads wird durch die Eigenschaft additionalInstances festgelegt. Stellen Sie sicher, dass Threads zugeteilt werden, nachdem eine Nachricht erstellt worden ist, aber bevor sie weitergegeben wird, damit immer nur ein Thread auf eine neue Nachricht wartet.

Der benutzerdefinierter Input-Knoten kann ein anderes Threading-Modell wählen und ist für die Implementierung des gewählten Modells verantwortlich. Wenn der Input-Knoten die EigenschaftadditionalInstances unterstützt und dispatchThread() aufgerufen wird, muss der Knoten voll simultan verwendbar sein, und eventuelle vom Knoten aufgerufene Funktionen sollten ebenfalls simultan verwendbar sein. Wenn der Input-Knoten Single-Threading erzwingt, also dispatchThread() nicht aufruft, dann muss in der Dokumentation zum Knoten angegeben werden, dass das Setzen der Eigenschaft additionalInstances keine Auswirkung auf den Input-Knoten hat.

Weitere Informationen zum Threading-Modell für benutzerdefinierte Input-Knoten finden Sie unter Hinweise zum Threading bei benutzerdefinierten Erweiterungen.

Löschen

Ein mit Java erstellter benutzerdefinierter Empfangsknoten wird vernichtet, wenn der Knoten gelöscht bzw. der Broker beendet wird. Im Code muss nicht definiert werden, dass der Knoten physisch gelöscht wird, dies übernimmt der Garbage-Kollektor.

Wenn Sie jedoch benachrichtigt werden wollen, wenn die Löschung eines Knotens bevorsteht, können Sie die Methode onDelete verwenden. Dies könnten Sie etwa wollen, wenn es andere Ressourcen gibt, die Sie löschen möchten, als die, die der Garbage-Collection unterliegen. Wenn Sie beispielsweise einen Socket geöffnet haben, wird dieser nicht ordnungsgemäß geschlossen, wenn der Knoten automatisch gelöscht wird. Sie können diese Anweisung in Ihre onDelete-Methode aufnehmen, um sicher zu stellen, dass der Socket ordnungsgemäß geschlossen wird.

Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:30:03

as24998_