Aug 15th, 2012, 07:32 PM
XMPP pubsub support and Event Driven Consumer
I have implemented a XMPP adapter for pubsub (XEP-0060).
The current implementation:
- XMPPPubSubMessageListeningEndpoint extends AbstractXmppConnectionAwareEndpoint extends MessageProducerSupport
- it has an instance of the Smack's PubSubManager.
- this PubSubManager will have an ItemEventListener added the node
- the node is for subscription.
- when an outside program publish to that node via XMPP, the Smack's ItemEventListener.handlePublishEvent() handles the arrived ItemPublishEvent by building the message with the itemPublishEvent straight up and sendMessage(message).
- My ItemEventListener is a inner class of the ListeningEndpoint, that's why I can call sendMessage(message).
- I made my XMPPPubSubMessageListeningEndpoint bind to the xmpp-inbound-channel-adapter, much like the original one (except using different namespace).
My splitter also splits the ItemPublishEvent into individual XMPP item:
All working fine, but my question is:
1. Should I use EventDrivenConsumer for XMPP Endpoint? After all, xmpp pubsub node from pubsub manager subscribes ItemEvent for a certain user.
2. Using a SubscribableChannel channel is a pre-requisite of using EventDrivenConsumer in this case
3. But do I need another MessageHandler for the subscribableChannel? It seems that I already have a ItemEventListener added to the pub sub node, that is responsible for sending the message.
Please help on reconciling the XMPP pubsub message model with the event driven consumer model in SI.
Aug 16th, 2012, 02:11 PM
After given some thoughts to my original question...
1. The AbstractXMPPConnectionAwareEndpoint is by nature a event driven adapter. I was extending that.
2. In the doStart() and doStop(), I have the Smack's PubSubManager to add the ItemEventListener.
3. The Listener handles the message by constructing and sending the Smack's ItemEvent downstream for the splitter to split into items.
4. If I use SubscribableChannel and EventConsumerEndpoint, the PubSubManager subscription logic will live in SubsribableChannel's message handler instead of the endpoint's doStart() and doStop(). But the cost is to inject the xmpp connection info into the SubscribableChannel.
I think either way would work, except not using the SubscribableChannel, the xsd and the namespace handler are much easier to follow and modify...
Hope someone would have shed some lights into this subject. Thanks for reading!