A JSR168-compliant implementation of inter-portlet communication

Note: there is now a new version of the messaging library available.

This portlet messaging library is intended for situations when:

  • You want to build an application out of several interacting portlets (e.g. a portlet which presents a list or index, and a number of portlets which display information about the selected item)
  • You've read this Tip on java.net and decided that the PortletSession is the way to go (if you wanted one of the other methods, have a look at Limitations in the Documentation)
  • You can't simply hardcode the messaging using APPLICATION_SCOPE session variables with known names, because:
    • Maybe you want many instances (windows) of the same portlet on the same page, or different pages, with each instance talking to different portlets
    • Maybe you want the user to be able to dynamically add new portlet instances (windows), and configure the 'wiring' of messages between portlets.
    • Maybe you want portlets in different portlet applications to communicate.

This is version 2.1 of a slightly more complicated messaging system, implemented for the Discovery Net project. Please let me know if you find it useful, or have any comments/advice/bugfixes that may make it better. The source is available and you're welcome to modify/use it however you like. It's licensed under the Apache License, Version 2.0.

New in version 2.1 (March 2006)

  • Improved Session ID retrieval for cross-context messaging:
    • using PortletRequest.getRequestedSessionId(), removing the need for strange hacks
  • Improved Portlet ID retrieval:
    • gets the actual Portlet Window ID used by the portal, rather than randomly-generating an ID at the start of each session.
  • Debug messages can be turned on/off
  • Applied the Apache License, Version 2.0, as a result of several queries!

New in version 2 (September 2005)

  • Cross-context messaging
  • Support for dynamic removal of message inputs/outputs

You can still get at the old pages for Version 1 and Version 2.

diagram showing basic messaging

Simple messaging model: message names in session must be hardcoded into the portlets

diagram showing messaging library

Advanced messaging model: message names in session do not need to be hardcoded. A Message Centre keeps track of all the mappings between local message names and global message names, allowing dynamic reconfiguration of message 'routes' by the administrator or the portal user.