Skip to main content

OpenPortal WSRP v2 milestone 2 : WSRP Coordination Preview


If you have not installed the WSRP version 2.0 milestone 2 binary, please follow the instructions available in the install guide before you proceed.

If you would like to keep track of future announcements and additions to the OpenPortal WSRP Project, please subscribe to the announce@wsrp.dev.java.net alias.

If you have questions on how to use the Open Portal WSRP Project and other comments/suggestions/requests, we urge you to join the users@wsrp.dev.java.net alias.

Please report any issues that you encounter while trying wsrp version 2.0 milestone 2 issues@wsrp.dev.java.net.



The milestone 2 previews the following WSRP version 2.0 optional features
  1. WSRP Eventing
  2. Shared/Public render parameters
The following sections details how to test and use these features and help you to understand the implementation.

Note : If you are interested in writing a JSR286 portlet that uses the above features please check the following document for more information. This document uses the binary that are available in the above mentioned document.

A. WSRP Eventing :


       The Portlet specification (JSR 286) allows portlets to communicate with each other using events. Events allows portlets to respond to actions or state change that may not be directly related to user action. 

WSRP complements this mechanism by extending these events to portlets that are published/consumed via the WSRP. WSRP 2.0 provides a mechanism by which a consumer can co-ordinate events between portlets. By consumer co-ordinated events we mean that a consumer could consume portlets from various location , these portlets could be from different producers or event local portlets. The Consumer managed co-ordination provides a option by which a consumer can distribute events across the portlets that it consumes. To state it simple words WSRP consumer coordinated eventing allows the following usages.
  1. It allows a remote portlet ( consumed from a producer ) to subscribe or publish events to local portlets on the consumer portal.
  2. It allows a remote portlet ( say consumed from producer A) on the consumer portal to subscribe or publish events to another remote portlet it consumed from producer B.
To demonstrate the WSRP eventing functionalities we'll use the following eventing sample portlet

The above application defines the following portlets
  1. World Map
  2. Continent Information and
  3. Continent Map Portlets
that participate in the event. Clicking on any continent in the world map triggers an event. This event is processed by the "Continent Information" and "Continent Map" portlets to show the relevant information.

The following screenshot displays these portlets being shown in the portlet driver.

screen shot


A.1 Sample Configuration :

Steps to configure WSRP Eventing within a single installation. This a loopback configuration where a Consumer points to a Producer which is deployed on the same box. Note : Eventhough both the Producer and Consumer are within the same JVM all communication happen over the wire between the Consumer and the Producer.

Prerequisite:
  1. Deploy the above portlet application using the portletdriver --> admin tab.
  2. These portlets appear on the portlets tab, Make sure that eventing is working by clicking on a continent in the World Map and see the other portlets display relevant information

Steps to configure WSRP:

  1. Create a WSRP Producer say "EventProducer" by clicking "New" button on the WSRP Producer Admin portlet
  2. Publish the "EventingMap.ContinentPortlet" and enable this WSRP Producer
  3. Now create a Consumer say "EventConsumer" that points to the above WSRP Producer WSDL URL - Make sure you choose version 2.0 (V2) while creating this Consumer.
  4. Click the "Create" link, to  create a WSRP Remote Portlet Window.
  5. Upon successful the above "Continent Portlet" would appear on the WSRP tab.
Choose/Click on a continent in the Portlet and see that the local portlets that are display in the "Portlets" tab display the relevant information.

The above configuration demonstrates a mechanism where an event fired by a remote portlets is propagated to the local portlet that are displayed or consumed by a consumer portal.

A.2 Advanced Configuration

In this configuration we'll try to consume the WSRP Producer deployed in a separate box.

Prepare two machines for this configuration , say Producer machine and Consumer machine ( alternatively you can have 2 domains on a single glassfish install or 2 glassfish install on the same box )

On Machine 1 :  Producer Machine
  1. Install glassfish
  2. Install Portlet container binary provided with WSRP v2 milestone 2
  3. Install WSRP v2 milestone 2
  4. Deploy the "Eventing Sample Portlet" application
  5. Create a WSRP Producer by publishing just the "EventingMap.ContinentPortlet"
On Machine 2 :  Consumer Machine
  1. Install glassfish
  2. Install Portlet container binary provided with WSRP v2 milestone 2
  3. Install WSRP v2 milestone 2
  4. Deploy the "Eventing Sample Portlet" application
  5. Create a WSRP Consumer which points to the above Producer machine
  6. Create a WSRP remote window for the above "ContinentPortlet" - This portlet will appear on the WSRP tab
Now click on a continent in the "ContinentPortlet" and see that the local portlet in the "Portlets" tab display the relevant information.

The above configuration demonstrated a usecase where a  remote portlet from a producer threw an event which got propagated to the local portlets that are deployed on the consumer portal. The difference as compared to the sample configuration is that that WSRP Producer and Consumer are deployed on separate box.

A.3 Feel free to play with other configurations

  1. A local portlet throwing a event and a remote portlet receiving the event
  2. Where a remote portlet from machine A throws a event to  another remote portlet from  machine B,  where these two portlets  are  consumer by a consumer portal on machine  C

B. Public Navigational/Public Render Parameters :

The other co-ordination mechanism that is introduced in WSRP 2.0 is Public Navigational Params. The JSR 286 specifications calls it as public render parameters. The public render params works  like a event the only difference is that the state is encoded in the URL and shared across portlets. Public render params are lightweight coordination mechanism where the coordination happens over the parameters encoded in the URL.

The difference between eventing and public render parameter is that, since public render parameter is encoded in the URL, the restrictions of the URL applied to the types of objects that can be shared between two portlets, where as in eventing its possible for two portlets to throw a event which is a complex data type.

To demonstrate the WSRP Public Navigational Parameters functionality we'll use the following Weather sample portlet. Please check the following document for more information on how to write a portlet using public render parameters. This document uses the binary that are available in the above mentioned document.

The Weather sample application   has 2 portlets namely
  1. Weather portlet and
  2. A Map portlets.
The Weather portlet sets the zip which is declared as a public render parameter. This parameter is shared by both Weather and Map portlets. Any change in the value of zip by Weather portlet is reflected during the render phase of both weather and map portlets.

The following screenshot displays these portlets being shown in the portlet driver.

screen shot of weather application

B.1 Sample Configuration :

Steps to configure WSRP Public Navigational Parameters within a single installation. This a loopback configuration where a Consumer points to a Producer which is deployed on the same box. Note : Eventhough both the Producer and Consumer are within the same JVM all communication happen over the wire between the Consumer and the Producer.

Prerequisite:
  1. Deploy Weather sample application portlet application using the portletdriver --> admin tab.
  2. These portlets appear on the portlets tab. Verify public render parameter functionality for JSR 286 local portles as follows. Make sure that editing the portlet and adding a  zip code in the Weather Portlet changes the state in the Map portlets by displaying relevant map information
Note : The Weather Portlet uses the yahoo  service, so if you  are behind a firewall make sure your glassfish install has the necessary proxy information. This enables the portlet to fetch information by contacting the yahoo weather service from the internet.

Steps to configure WSRP:

  1. Create a WSRP Producer say "SharedrenderProducer" by clicking "New" button on the WSRP Producer Admin portlet
  2. Publish the "WeatherMap.WeatherPortlet" and enable this WSRP Producer
  3. Now create a Consumer say "SharedrenderConsumer" that points to the above WSRP Producer WSDL URL - Make sure you choose version 2.0 (V2) while creating this Consumer.
  4. Click the "Create" link against "SharedrenderConsumer" consumer, to  create a WSRP Remote Portlet Window.
  5. Upon successful the above "Weather Portlet" would appear on the WSRP tab.
Sign in to portletdriver and click on "WSRP" tab. Edit the remote Weather Portlet and provide a zip code. It should bring the weather report for provided zip code.
Now click on "Portlet" tab and see that the local portlets (Weather and Map Portlet) display the information according to new zip code.

The above configuration demonstrates a mechanism where a remote portlets public render parameters are propagated to the local portlet that are displayed or consumed by a consumer portal.

B.2 Advanced Configuration

In this configuration we'll try to consume the WSRP Producer deployed in a separate box.

Prepare two machines for this configuration , say Producer machine and Consumer machine ( alternatively you can have 2 domains on a single glassfish install or 2 glassfish install on the same box )

On Machine 1 :  Producer Machine
  1. Install glassfish
  2. Install Portlet container binary provided with WSRP v2 milestone 2
  3. Install WSRP v2 milestone 2
  4. Deploy the "Weather Sample" application
  5. Create a WSRP Producer by publishing just the "WeatherMap.WeatherPortlet"
On Machine 2 :  Consumer Machine
  1. Install glassfish
  2. Install Portlet container binary provided with WSRP v2 milestone 2
  3. Install WSRP v2 milestone 2
  4. Deploy the "Weather Sample" application
  5. Create a WSRP Consumer which points to the above Producer machine
  6. Create a WSRP remote window for the above "WeatherPortlet" - This portlet will appear on the WSRP tab
Edit the Weather Portlet and provide a zip code and see that the local portlet(Map Portlet) in the "Portlets" tab display the relevant information map information.

The above configuration demonstrates a mechanism where a remote portlets shared render parameters are propagated to the local portlet that are displayed or consumed by a consumer portal. The difference as compared to the sample configuration is that that WSRP Producer and Consumer are deployed on separate box

B.3 Feel free to play with other configurations

  1. A local portlet producing a public render parameter to a remote portlet which consumes it.
  2. Where a remote portlet from machine A shares a render parameter with another remote portlet from  machine B, where these two portlets are consumed by a consumer portal on machine  C
 
 
Close
loading
Please Confirm
Close