It’s fine that KNIME enables us to integrate with other applications using JMS by introducing a community JMS Connector node.
But the node supports the request-response pattern which is not the only one integration scenarios make do with.
The node obviously acts the way it sends a single message and waits for a response to appear in the destination configured as Reply to Queue (or just hangs waiting if no configuration of reply-to is provided).
It’d be great if the node supported other scenarios:
Just send a message, don’t wait for a response (Fire and Forget pattern).
Just receive messages from a destination. Don’t send anything.
Your observations are correct. Just to give you a bit of background: the node was created and published in 2012 and it has not received any update since then.
The rationale behind the decision of making it synchronous responds to a need I had back then to use a flow within a SOAP-based communication, in which most of the messages sent to an ESB wait for an answer instead of having a call-back endpoint (or queue/topic) to be notified upon task completion, if required.
For the second item you describe, I don’t think it will be possible to have that feature in the current node and I would rather think of a separate one.
However, I regret to communicate that currently I am not planning to keep working on the node, so feel free to make the changes you consider necessary (prior checking/updating JMS version) and share with KNIME community.
thanks a lot for your answer! And thank you for providing the community with the node! I’ve got your point .
Well, I prepare for developing my own nodes time to time but I haven’t got brave enough yet to start with it.
For now I plan to interact with a messaging server using custom Java logic & External Tool node as @ipazin recommended in another topic (LDAP integration).