In der Registrierungsphase macht sich ein in Java geschriebener benutzerdefinierter Empfangsknoten 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. A0n diesem Punkt wird die statische Methode getNodeName aufgerufen, und der Broker registriert den Empfangsknoten 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.
Die Instanzerstellung eines mit Java erstellten benutzerdefinierten Empfangsknotens erfolgt, wenn der Broker einen Nachrichtenfluss einsetzt, der diesen benutzerdefinierten Empfangsknoten enthält. Nach Erstellen der Knoteninstanz wird der Konstruktor der Klasse des Empfangsknotens 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 Sie die Ausnahmen, die an den Empfangsknoten zurückgegeben werden, verarbeiten möchten, erstellen Sie mit Hilfe von createOutputTerminal ein Catch-Terminal für den Empfangsknoten. Wenn dann vom Empfangsknoten ein Fehler abgefangen wird, wird dieser vom Catch-Terminal in derselben Weise verarbeitet wie von einem normalen MQEmpfangsknoten. 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 Empfangsknoten 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 Empfangsknoten übergeben wird, sollte der entsprechende Code an dieser Stelle des Empfangsknotens eingefügt werden.
Die Nachrichtenverarbeitung für einen Empfangsknoten beginnt beim Aufruf der Methode run durch den Broker. Die Methode run erstellt die Eingabenachricht und sollte die Verarbeitungsfunktion für den Empfangsknoten enthalten.
Die Definition der Methode run erfolgt über MbInputNodeInterface, also die Schnittstelle eines benutzerdefinierten Empfangsknotens, die diesen erst als Empfangsknoten definiert. Der Knoten muss die Methode 'run' enthalten. Beinhaltet der benutzerdefinierte Empfangsknoten nicht die Methode run, kann der Quellcode des Knotens nicht kompiliert werden.
Wird ein Nachrichtenfluss mit einem benutzerdefinierten Empfangsknoten 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 Empfangsknotens 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 Empfangsknotens 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. Das empfohlene Modell ist, sicher zu stellen, dass Threads zugeteilt werden, nachdem eine Nachricht erstellt worden ist, aber bevor sie weitergegeben wird. Somit wird sichergestellt, dass jeweils nur ein Thread auf eine neue Nachricht wartet.
Der benutzerdefinierter Empfangsknoten kann ein anderes Threading-Modell wählen und ist für die Implementierung des gewählten Modells verantwortlich. Wenn der Empfangsknoten 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 Empfangsknoten Single-Threading erzwingt, also dispatchThread(), nicht aufruft, dann sollte dem Benutzer des Knotens klar gemacht werden, dass das Setzen der Eigenschaft additionalInstances keine Auswirkung auf den Empfangsknoten hat.
Weitere Informationen zum Threading-Modell für benutzerdefinierte Empfangsknoten finden Sie unter Threading.
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.