I have been reading about WSRP.
From the technical specs, and public opinions, I have to conclude that WSRP should not be considered as a viable option for integration between portal technologies for the foreseeable future.
The WSRP idea has been thrown around as a great solution to cross platform reuse of portal components, but the reality is that the spec and implementations are still in early stages due to vagueness and complexity, and some legal issues (there's a patent involved). The intent of the WSRP spec is to provide guidelines on how and when to call APIs to deal with user context, caching, sessions, discovery, security, etc… All good ideas, but when it comes to implementation, vagueness in security alone (which the spec doesn't advise anything specific) can be enough to kill connectivity.
WSRP is based on the idea that a web service can deliver fully rendered HTML chunks to a consuming portal typically based on the current user's access and preferences. Because web services are classically intended to provide data, and not UI or aesthetic content, WSRP web services are considered "presentation-oriented web services" and are potentially involved with dynamically provisioning user accounts and saving user preferences. The other significant part of WSRP is that all user interaction (web links) get funneled back to the provider presentation oriented web services for proper event handling.
The best solution (rather than WSRP) is to keep with the standard goals for web services providing data, and to write light-weight portlets/webparts. Then port the light-weight portlets/webparts rather than deal with the user/session/state/security/UI issues the comes with WSRP.
Consider the portability of combining pure web service data, server side XSL transformations, JS/AJAX for HTTP submissions (possibly directly from client JS to the web service). The web portal server side processing could be kept down to a minimum common functionality of a generic XSLT (which they should all support) portlet/webpart.