Basics of WSRP #
Quoting for the specification itself:
The Web Services for Remote Portlets specification defines a web service interface for accessing and interacting with interactive presentation-oriented web services.
But... since we have Web Services and we have Portlets, why do we need WSRP then?
Well, it is true that you can provide platform-independent access to our services via Web Services. However, to allow the user access to those services you would need to build a presentation logic and user interface. And sometimes, that can take many effort and time, to develop, compile and deploy the presentation to the end-user.
And that is the key in the WSRP definition: presentation-oriented web services.
WSRP specification is about going much further and allow portals to display remote portlets inside their pages, as if locallly deployed, without requiring any additional programming by the developers.
So you will be providing access to your business logic but also providing the user interface!
In order to do so, WSRP define the following actors:
- Producer: A Web Service that offers one or more portlets and is described using a WSDL document.
- Consumer: The Web Service Client that gather all the components allowing for the presentation to the end user.
- End Users
WSRP in Liferay #
Liferay supports WSRP 2.0 specification and can act as a WSRP Producer and Consumer.
From the image above, Liferay portal server can be used as a WSRP Producer, hosting portlets that will be consumed by other Liferay portal servers acting as WSRP Consumers.
So, with WSRP you are delivering both, data and presentation in a way that decouples deployment and delivery of your portlets.
And with Liferay you don't need any extra development in order to start enjoying WSRP advantages just deploy the WSRP plugin porltlet and start using it!
Deploy WSRP plugin #
As you know, there are different ways of deploying a plugin in the portal, we are going to deploy the WSRP plugin through the UI, so go to the 'Control Panel' and 'Plugins Installation' and click on 'Install more portlet':
Look for WSRP and install it:
Once installed, refresh your page and you will be able to see it available in the 'Control Panel':
And as easy as that you can just start creating producers and consumers for your portal.
Liferay Producer #
Let's go ahead and create a producer. Go to the 'Producers' tab in the WSRP portlet and click the 'Add Producer' button:
Now, you can see here a list of portlets that your producer may use. Let's stick pick the 'Currency Converter' and, of course, the 'Hello World':
Once you click the Save button the portal will have generated a WSDL to define your producer. To be able to see the URL click 'Action' -> 'Edit':
Copying that URL to the browser you will see the WSDL definition for your producer.
Liferay Consumer #
For the purposes of this exercise we are going to use the same Liferay installation as producer and consumer, but we could go with this WSDL definition to the Liferay server acting as consumer and define the consumer pointing to another server.
For now, let's go to the 'Consumers' tab and click the 'Add Consumer' button:
Give it a name, add the URL to the WSDL for the producer and click 'Save':
Lastly, we need to define the portlets that the end-user will be able to use from this consumer. To do so, go to the list of consumers and in 'Actions' click 'Manage Portlets':
Then, add the two portlets that this producer is exposing to the consumer, so that the end-user can used them in the portal:
Accessing Remote Portlets #
Now, let's use the remote portlets from the portal. Go back to your community and click the 'Add Application' in the dock bar, 'More...' and go to the WSRP category:
Add them to your page:
There you go! You are consuming 'remote' portlets with Liferay WSRP implementation.
Custom Remote Portlets #
You can make your custom developed portlets remotely accessible by setting to 'true' the <remotable> tag in your liferay-portlet.xml:
<liferay-portlet-app> <portlet> <portlet-name>RemotePortletTest</portlet-name> <remoteable>true</remoteable> ….......
By doing this your custom portlet will appear in the list of portlets available when creating a WSRP producer, so you can expose all your custom developed portlets to be used by consumers.
Portlets Modes #
All three standard portlet modes (VIEW, EDIT, HELP) are supported by Liferay's implementation of WSRP.
Since the EDIT mode requires the user to be authenticated, you will need to enable request header authentication in your portal, specially on the producer for the credentials to be propagated through HTTP headers.
This is done by adding a reference to a Liferay class com.liferay.portal.security.auth.RequestHeaderAutoLogin to the property auto.login.hooks in your portal-ext.properties, (to be used with another security product such as Tivoli Access Manager, etc.)
For fine-tune your HTTP settings have a look at the HTTP section in the portal.properties and system.properties