Thursday, October 05, 2006

WSRP in Peoplesoft

Someone wrote me regarding WSRP advice. As often I'm reluctant to answer questions without answering them out loud and in public where others can see what is being said and either use it or disagree.


I've been developing JSR-168 Portlets for uPortal for a while and our management decided to change our portal framework from uPortal to PeopleSoft Portal. I'm hoping to reuse some of the work we've done by using WSRP. I know that uPortal has supported WSRP (except for hiccups). However, I'm having touble finding any technical information on developing a WSRP portlet (seems that there is little on the web or in printed material showing examples of WSRP code). I was wondering if you could point me towards some information regarding developing WSRP producers.


I'm reluctant to recommend WSRP as a solution to any real problem.

PeopleSoft does expose WSRP and so I suppose one could decide to
consume that WSRP in a portal. My gut reaction to the whole thing is
that it would be better architected if PeopleSoft had delivered
JSR-168 portlets that consumed domain-specific web services under the
hood. WSRP fundamentally is a protocol for remoting the production of
portlet *markup*, and that's strange.

You've articulated a different problem. You have a WSRP consuming
portal (PeopleSoft) that you'd like to get content into.

Michael Ivanov, Matthew Dovey, and others have been more involved in
uPortal WSRP.

I hear this is easier over in the .NET world, writing WSRP producers.
Don't know much about that.

In the Java world, what you do is you write a JSR-168 portlet and then
front it with WSRP4j to expose the portlet. uPortal 3 also has WSRP
producer infrastructure, such that it can produce WSRP around portlets
running in it. Sakai also produces WSRP. All of this either is or is
built on WSRP4j.

In theory you could run uPortal and use it to serve JSR-168 portlets as a WSRP Producer to a PeopleSoft portal instance which would present them to end users.

No comments: