+

Search Tips   |   Advanced Search


Event broker

The portal event broker subsystem provides support for inter-portlet communication with active notifications using portlet events or the cooperative programming model.

The event broker is based on a loosely coupled publish/subscribe communication model: participating portlets declare the messages or data types that they can publish and consume, but do not need to know about the actual communication structure. Depending on the programming model that you use, sources and targets are defined and implemented in a different way (refer to the documentation about interoperability between events and cooperative portlets), but on the level of concepts described here, they are treated the same way.

The following explanations apply to standard based portlets.

How messages are distributed between portlets is determined by portlet wires that are defined as part of page editing. Portlet wires link a defined output of one portlet on a page to a defined input of another portlet on the same page or on a different page.

The wiring step is separate from portlet development and deployment. This allows independent development of source and target portlets, as long as both portlets use common data types and semantics for information exchange. Portlets can operate standalone, and, as partner portlets for the communication are added by editing pages, they can exchange information and react in a coordinated manner, and thereby improving the end-user experience. Conversely, as portlets are removed, the remaining portlets still work correctly.


Parent topic:

Portlet communication


Related concepts


Shared portlet state
Publish/subscribe message based communication
Special purpose techniques for data exchange
Cooperative portlets
Portlet wires
Public render parameters


Related reference


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


Runtime behavior

The processing cycle of a portal request is divided into an action/event phase which processes user input and a render phase which generates markup output. The activity of the event broker subsystem occurs during the action/event phase. Event processing is usually initiated by a portlet action that is encoded in the current request URL.

For example, this can be a portlet action URL, or a URL generated by a click-to-action menu. For requests that do not require portlet activity, but just produce output, the action/event phase can be skipped entirely.

If the request specifies a portlet action, that action will be executed and may itself publish output, either as a JSR 286 event or as a cooperative portlet property. If that output is wired to the input of one or more other portlets, a call to the processing methods of these portlets is put into the event queue. When the first portlet action is completed, the next event is taken from the queue and the target portlet is invoked. In the course of the event processing, the target portlet can trigger further communication calls which are then also queued. This process repeats until the queue is empty.

This allows the synchronization of multiple portlets within a single request-response cycle.

For example, in a context of a customer order for some goods, all of the following can happen:

  1. Transfer of the order ID to the Order Details portlet.

  2. This first step also triggers the transfer of the tracking ID for the order to the Tracking Details portlet

  3. The Tracking details portlet in turn triggers the transfer of the customer name associated with the order to the Customer Details portlet.

  4. Consequently, all three portlets display information that pertain to the same customer order.

To avoid infinite loops, event distribution will also stop when a maximum limit of portlet calls is reached; this is considered an error situation and should be avoided.

Event processing is completely sequential and never nested within one client request; each target event or action is fully processed before the next one is invoked. The portal guarantees that the order in which events are delivered to a single target preserves the order in which the events were published. However, for performance reasons, events for different targets may be re-ordered to minimize context switches.


Cross-page communication

Wires can link source output from a portlet on one page to target events of other portlets on different pages. All targets, whether on the same page or on different pages, are processed within the action/event phase of one request cycle. A redirect to the target page can be sent only after the entire action/event phase has been completed. For details about wiring and cross-page wires, refer to the documentation about portlet wires.

This behavior implies that the target portlet that receives event or action calls from a cross-page wire can be on a different page than the current page. In other words the "current page" at execution time can be different from the page that contains the target portlet. Portlet code that relies on retrieving programmatic information about the current page context during the action/event phase should be prepared to handle this case.