User presence is the domain normally represented by instant messaging systems, and while libraries supporting presence have existed for Java for a while, presence isn't normally represented in J2EE. The application domain for user presence is large. The monitoring subsystem of a J2EE application requires presence information to effectively route reports and alerts to monitoring operators. VoIP applications such as call centers can forward calls to available users and voice mail can be automatically activated for users whose presence is marked as 'extended-away' or 'off line'. Workflow-based systems that assign tasks to users as part of a workflow execution (such as those used in banking operations or hosting provisioning operations) cannot be reasonably efficient without having at their disposal the presence state of their operators pool. Finally, help-desk applications require a real-time view of the available assistants. "Integrating Presence into J2EE Environments," by John Georgiadis, shows how to change this, by using OpenFire from Jive Software to provide XMPP support to a J2EE environment. Read Article

You might want to provide a link to the article. https://www.theserverside.com/tt/articles/article.tss?l=IntegratingPresenceJ2EEEnvironments

Great article: important, clear and practical. Now if you replace JMS with AMQP, you would have a totally protocol-centric language-neutral platform-independent architecture-of-the-future. Mik

I think this would fall right inline with the XMPP BC and the SIP BC we have developed under java.net.

I agree, JBI is the future. But in this situation presence change notification was needed for all XMPP users. By only using smack, the restrictions of XMPP on the dissemination of presence information cannot be overcome. In addition, the article tries to make 2 points: 1. How powerful the plugin mechanism of OpenFire is 2. In many cases, even after the introduction of new container types for J2EE, JMS remains a strong integration solution.