27.1 Overview
In this scenario, two different versions of the same portlet, called Echo portlet, are used. You will change the portlet UID of one of the portlets to be able to run the two portlets in the Portal Test Environment. As and option, you will also change the portlet name and the portlet title to visually identify the portlets.
The Echo portlet has a simple form that allows the user to enter a message. When the message is submitted, it is displayed back on the same portlet. In this scenario, the portlets will be enhanced to work in a cooperative portlet environment.
The following portlets are used:
![]()
The source cooperative portlet, named EchoSource, shows a form to submit a message and will be enhanced to send the message to the Cooperative Portlets property broker.
![]()
The target cooperative portlet, named EchoTarget, will be enhanced to receive the message from the Cooperative Portlets property broker and display it.
The Cooperative Portlets property broker uses Struts Actions to notify input properties.
The sample scenario is illustrated in Figure 27-1. The Struts source portlet publishes (broadcasts) an output property and the Struts target portlet receives the message.
Figure 27-1 Cooperative Portlets sample scenario
This scenario shows various cooperative portlet concepts in Struts portlets using the JSR 168 API.For example:
![]()
You will enable portlet cooperation using a declarative approach. For JSR 168 compliant portlets, WSDL is the only way to provide information about portlet actions as programmatic cooperative portlets are not available for JSR 168 portlets.
![]()
You will create wires between cooperative portlets using the Portlet Wiring Tool. This is the only way to connect JSR 168 compliant portlets as Click-to-Action is not available for JSR 168 portlets.
ibm.com/redbooks