Le informazioni contenute in questo argomento sono valide sia per i nodi di output che per i nodi di elaborazione dei messaggi. Entrambi questi tipi di nodi possono essere considerati insieme in quanto, sebbene un nodo di elaborazione dei messaggi venga usato di solito per elaborare un messaggio e un nodo di output venga utilizzato per fornire un output nella forma di un flusso di bit, da un messaggio, per eseguire tali funzioni è possibile utilizzare l'uno o l'altro tipo di nodo.
La fase di registrazione di verifica quando un nodo di elaborazione dei messaggi definito dall'utente scritto in Java si rende riconoscibile al broker o si registra con il broker.
Ogni volta che un broker viene avviato, carica tutte le classi Java e le LIL di rilievo. Per essere certi che un nodo di elaborazione dei messaggi venga registrato con il broker, è necessario fornire al broker una classe che implementa l'interfaccia MbNodeInterface e sia contenuta nel classpath del broker.
Viene creata l'istanza di un nodo di elaborazione dei messaggi definito dall'utente in Java quando un broker distribuisce un flusso di messaggi contenente il nodo di elaborazione dei messaggi definito dall'utente. Quando viene creata l'istanza del nodo, viene richiamato il costruttore della classe del nodo di elaborazione dei messaggi.
Quando viene creata l'istanza di un nodo, vengono creati i terminali che sono stati specificati. Ad un nodo di elaborazione messaggi possono essere associati una serie di terminali di input e di output. Al fine di dichiarare tali terminali, è necessario includere i metodi createInputTerminal e createOutputTerminal nel costruttore del nodo.
I terminali di output includono i terminali out, failure e catch. Utilizzare la classe createOutputTerminal all'interno del costruttore di classe del nodo per creare il numero di terminali di output richiesti.
Come minimo, è necessario creare solamente questi terminali di output utilizzando la classe del costruttore. Tuttavia, se si ha necessità di inizializzare i valori di attributo, è necessario includere anche tale codice in questo punto nel nodo di elaborazione dei messaggi.
Se si desidera gestire le eccezioni che sono ripassate al al nodo di elaborazione dei messaggi, è buona pratica effettuare ciò creando un terminale failure per il nodo di elaborazione dei messaggi definito dall'utente, mediante l'uso del metodo createOutputTerminal. E' consigliabile utilizzare il terminale failure per tale elaborazione in quanto è qui che vengono distribuiti gli errori WebSphere Message Broker.
Accertarsi che le eccezioni rilevate dal nodo di elaborazione dei messaggi siano trattate correttamente. Se non si include un terminale failure, il nodo di elaborazione dei messaggi non tenterà di gestire l'eccezione. Se il flusso di messaggi non contiene alcun metodo di gestione di eccezioni, le eccezioni generate vengono ripassate al nodo di input che se ne fa carico.
Se si esegue il catch di eccezioni, accertarsi che vengano rigenerate le eccezioni di cui il nodo di elaborazione dei messaggi non si può occupare. Questo fa sì che le eccezioni vengano ripassate al nodo di input per la gestione, ad esempio, quando si desidera eseguire il rollback di una transazione.
Durante la fase di elaborazione del ciclo di vita di un nodo di elaborazione dei messaggi definito dall'utente, il nodo di elaborazione dei messaggi assume la gerarchia logica del messaggio e ne esegue in qualche modo l'elaborazione.
Un nodo di elaborazione dei messaggi definito dall'utente in Java viene eliminato quando il nodo viene cancellato o quando il broker viene chiuso. Non è necessario inserire nulla nel codice che specifichi l'eliminazione fisica del nodo, in quando ciò può essere gestito dal garbage collector.
Tuttavia, se si desidera ricevere una notifica quando viene eseguita l'eliminazione di un nodo, è possibile utilizzare il metodo onDelete. Ciò potrebbe essere utile se sono presenti risorse che si desidera eliminare, diverse da quelle che verranno gestite dal garbage collector. Ad esempio, se è stato aperto un socket, questo non verrà chiuso correttamente quando il nodo viene eliminato automaticamente. E' possibile quindi includere tale istruzione nel metodo onDelete per essere certi che il socket venga chiuso correttamente.