+

Search Tips   |   Advanced Search


Publish/subscribe message based communication

These communication methods are based on directed communication links that pass information from a source portlet to a target portlet.

The portlet programmer defines which information a portlet can send or receive in order to participate in the communication. At run time data is passed by an event broker component across communication links that are created by administrators or end users. When data is sent across a link, the target portlet is explicitly invoked to process the received information and can perform arbitrary updates as a side-effect. This is called the push model. Previously cached markup is discarded as a result of receiving an event.

Message based communication allows more programmatic and administrative control than shared state, but also creates more overhead. If you need to coordinate many portlets and create a large number of connections, consider using shared state instead.


Parent topic:

Portlet communication


Related concepts


Shared portlet state
Special purpose techniques for data exchange
Cooperative portlets
Event broker
Portlet wires
Public render parameters


Related reference


Portlet events
Interoperability between events and cooperative portlets
Known issues and restrictions with portlet communication


Communication with persistent wires

The following two communication techniques are based on persistent data links, also called portlet wires. The wires have to be configured in a separate step before the portlets can communicate:

Portlet events

This supports JSR 286 portlets only. The Java Portlet Specification 2.0 defines a model for communication by publishing and subscribing based on portlet events. This model is supported in WebSphere Portal v6.1.5. Portlet events can have complex objects as payload, if they provide an XML binding. With portlet events, WebSphere Portal 6.1 also supports communication links between remote (WSRP V2.0) portlets.

Cooperative portlets

OnlyJSR 286 portlets support this communication technique. WebSphere Portal v6.1.5 still supports the IBM specific cooperative portlet programming API that was provided by previous releases and is known as the Property Broker. However, if you develop new portlets, use the portlet events based on the JSR 286 standard instead. It provides equivalent and compatible functionality.

For more information about moving from cooperative portlets to JSR 286 events, refer to Interoperability between events and cooperative portlets.

Note that you can create communication links in both directions between JSR 286 portlets and JSR 168 portlets by using the cooperative portlet API. However, that API does not support communication links between IBM and JSR 168 portlets.


Communication with dynamic menus

The following two communication techniques are based on dynamically generated menus that allow portal users to select a target destination for displayed data at run time:

Live text based click-to-action

This technique works for JSR 168 and JSR 286 portlets only. The portal supports client side creation of dynamic action menus based on live text. This means that source data items on a portal page can be tagged with semantic HTML to serve as menu anchors. You can provide tagged source data by any type of HTML fragment on a page. This includes portlets, themes, or external content inside a rendering portlet. You can also define targets by using semantic HTML. In addition to such targets explicitly coded in HTML, the portal makes portlet events or cooperative portlet actions for portlets on the page automatically available as targets.

Server-generated click-to-action menus

The cooperative portlet support for IBM portlets includes click-to-action JSP tags that compute pop-up menus that list the available targets actions for a data item. When the user selects a specific action, the data is delivered without an explicit wire between the source and the target.

The user can also broadcast the data to all available targets. Finally, the user can create a persistent wire as the side effect of a target selection. If a wire is present the next time the user clicks on the click-to-action icon, no selection menu is shown, and the wired target action is automatically triggered.

This technique works for IBM legacy portlets only and should otherwise not be used.