File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Portals and Portlets and the fly likes Remote Portlets + WSRP + JSR 168 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Portals and Portlets
Bookmark "Remote Portlets + WSRP + JSR 168" Watch "Remote Portlets + WSRP + JSR 168" New topic

Remote Portlets + WSRP + JSR 168

Rohit Mehra

Joined: Mar 09, 2011
Posts: 1

I have just started working on portlets & remote portlets.

I want to implement
1) Create Producer portlet running on Jboss portal server 1
2) Create Consumer portlet running on Jboss portal server 2
3) Session managment between both of them.

Can anybody help me to implement the above scenario using JSR 168 specifications?
David O'Meara

Joined: Mar 06, 2001
Posts: 13459

assuming you're clustering the JBoss instances and JBoss server supports WSRP (I haven't checked) it depends what your require in Session Management.
eg I just finished doing some fairly extensive WSRP testing using Liferay and the support is very good, but while the Portlet spec defines management of state between portlets and portlet instances it does not define any inter-portlet state management. ie the how portlets would maintain and share session state. Portlets are supposed to communicate via IPC (JSR 286 not 168) and this is covered by WSRP, but again the concept of session-based state is not.

Stepping back to Liferay for a second, there are a few ways to share session state using Liferay-specific mechanisms and it is also possible to access the HTTP Session directly to manipulate state. Regardless of how you maintain state and of whether you share state between portlets, the portal server tends to provide support for portlet state by delegating to the HTTP session and adding a prefix to the binding name to maintain a unique namespace and prevent collision. Because of this, portlet session clustering can be left to the general HTTP session clustering provided by the application server.

With a few provisos:
In Liferay (maybe others) a WSRP Consumer needs server affinity with a WSRP Producer for each conversation (is sticky connections). If you have multiple portlets, they need to be announced on the producer in a single WSRP Producer and they need to made available on the consumer using a single WSRP Consumer. If you do anything else, or have a mixture of remote and local portlets, you may find that session sharing fails.

That's more or less a direct brain dump of the WSRP session state testing we did with Liferay 6EE SP1
I agree. Here's the link:
subject: Remote Portlets + WSRP + JSR 168
It's not a secret anymore!