Durante la fase di registrazione un nodo di input definito dall'utente scritto in Java si rende riconoscibile al broker. Il nodo è registrato con il broker mediante il metodo getNodeName statico. Ogni volta che un broker viene avviato, carica tutte le classi Java di rilievo. Viene quindi richiamato il metodo statico getNodeName e il broker registra il nodo di input con il nome di nodo specificato nel metodo getNodeName. Se non si specifica un nome di nodo, il broker ne crea automaticamente uno tenendo conto del pacchetto in cui è contenuto.
Se si utilizza qui un metodo statico significa che il metodo può essere richiamato dal broker prima che venga creata l'istanza del nodo stesso.
Viene creata l'istanza di un nodo di input definito dall'utente in Java quando un broker distribuisce un flusso di messaggi contenente il nodo di input definito dall'utente. Quando viene creata l'istanza del nodo, viene richiamato il costruttore della classe del nodo di input.
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.
Se si desidera gestire eccezioni che vengono ripassate al nodo di input, è necessario utilizzare createOutputTerminal per creare un terminale catch per il nodo di input. Quando il nodo di input acquisisce un errore, il terminale catch lo elabora nello stesso modo di un un normale nodo MQInput. E' possibile abilitare la maggior parte delle eccezioni, come ad esempio eccezioni derivanti da problemi di distribuzione, di ripassare al broker, e il broker avvertirà l'utente della possibilità di errori di configurazione.
Come minimo, la classe del costruttore deve creare solamente questi terminali di output sul nodo di input. Tuttavia, se si ha necessità di inizializzare i valori di attributo, come ad esempio definire il programma di analisi che analizzerà inizialmente un messaggio passato dal nodo di input, è necessario includere anche tale codice in questo punto nel nodo di input.
L'elaborazione messaggi per un nodo di input inizia quando il broker richiama il metodo run. Il metodo run crea il messaggio di input e deve contenere la funzione di elaborazione per il nodo di input.
Il metodo run è definito in MbInputNodeInterface, che è l'interfaccia utilizzata in un nodo di input definito dall'utente che lo definisce come un nodo di input. Nel nodo è necessario includere un metodo "run". Se il metodo run non viene incluso nel nodo di input definito dall'utente, non verrà eseguita la compilazione del codice di origine del nodo.
Quando un flusso di messaggi contenente un nodo di input definito dall'utente viene distribuito con esito positivo, il broker richiama il metodo di implementazione "run" del nodo e continua a richiamare tale metodo mentre attende l'elaborazione dei messaggi.
Quando viene avviato un flusso di messaggi, il broker invia un singolo thread che viene richiamato nel metodo run del nodo di input. Se viene richiamato il metodo dispatchThread(), nello stesso metodo run è possibile creare ulteriori thread. Questi nuovi thread vengono richiamati immediatamente nel metodo run del nodo di input e possono essere trattati come il thread di origine. Il numero di nuovi thread che è possibile creare è definito dalla proprietà additionalInstances. E' consigliabile accertarsi che i thread vengano inviati dopo la creazione di un messaggio e prima che questo venga distribuito. In questo modo si è certi che un solo thread alla volta sia in attesa di un nuovo messaggio.
Il nodo di input definito dall'utente può scegliere un modello di thread diverso ed è responsabile dell'implementazione di tale modello. Se il nodo di input supporta la proprietà additionalInstances, e si richiama dispatchThread(), il codice deve essere completamente rientrante e lo devono essere anche le funzioni che vengono richiamate dal nodo. Se il nodo di input forza il thread singolo, ovvero, non richiama dispatchThread(), è necessario che l'utente di tale nodo sia consapevole che l'impostazione della proprietà additionalInstances non avrà alcun effetto sul nodo di input.
Per ulteriori informazioni sul modello di thread per i nodi di input definiti dall'utente, fare riferimento a Uso di thread.
Un nodo di input 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.