Marc Logemann has posted "No WSRP Producer example. Is WSRP dead?," asking about the availability of a WSRP service for testing. WSRP is an OASIS protocol for portals to display content hosted on a different server than the portal itself. There are various WSRP implementations in the wild, including an implementation on Java.net (https://wsrp.dev.java.net/) but it's certainly worth wondering how one can successfully test, if services are hard to find.

Several vendors have hosted WSRP producers out there - as indicated in the blog responses. Also, just because there are no public WSRP producers on the public Web, doesn't mean that it's not being used.

What a silly question? Looks like the poster did not take the take time to look around before posting! Subbu

I've used WSRP several times before. It's quite alive and works very well. I've used it specifically to publish portlets written in .Net to a portal written in Java.

...I've used it specifically to publish portlets written in .Net to a portal written in Java.

How? Did you use 3rd party s/w like NetUnity? Cheers: Ashok Shetty

Given that this specification is around for a while this is a valid question. There is only fairly "basic" stuff available. Also, most portlets that are developed tie into a specific context, at the very least with some inter-portlet communication, that you may simply not have with federated WSRP. And trying to establish it can become a real nightmare, bandwidth-wise, operational-wise etc.

Given that this specification is around for a while this is a valid question. There is only fairly "basic" stuff available. Also, most portlets that are developed tie into a specific context, at the very least with some inter-portlet communication, that you may simply not have with federated WSRP. And trying to establish it can become a real nightmare, bandwidth-wise, operational-wise etc.

We only have a few customers using WSRP that I know of. It is a necessary technology, and we worked pretty closely with the BEA portal group and customers (e.g. Wells Fargo Bank) to provide shared context patterns for WSRP, since that is the basic missing piece of the spec. Without shared context, you can easily end up with consistency issues, even if you are passing megabytes of information around using WSRP (==slow), because the providers are each working independently and from the old state of the context if they are running in parallel. See: http://dev2dev.bea.com/pub/a/2005/11/federated-portal-cache.html Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

A nice showcase for using caching. Is this a "necessary technology" or a "necessary technology to sell coherence" :-). Sorry couldn't resist.... On a slightly different note, I did never like the way the request and response were formulated in the original WSRP spec. Far too much "presentation centric" stuff that makes it very hard to adapt to corporate identity etc. but for the trivial case. I would have like a spec that defines XML/XSL and requires a default XSL. Haven't looked at WSRP lately though.

A nice showcase for using caching. Is this a "necessary technology" or a "necessary technology to sell coherence" :-). Sorry couldn't resist....

You should always ask that question when a vendor is involved .. ;-) In this case, it was an existing customer with a problem that they couldn't easily solve.

On a slightly different note, I did never like the way the request and response were formulated in the original WSRP spec. Far too much "presentation centric" stuff that makes it very hard to adapt to corporate identity etc.

Regarding the spec, the 1.0 was very weak, but 1.1 was workable and 2.0 (which BEA has largely supported for over a year, IIRC) seemed to be pretty good. My knowledge of the spec mainly came from Alex Ruiz (who was on the BEA Portal team) and some of the architects and engineers at Wells Fargo and Pfizer. Which version were you referring to? The real promise of WSRP (IMHO) is the ability to aggregate across servers from various vendors, theoretically capable of grabbing content that wasn't necessarily intended to be aggregated. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

As always its nice to see that there are some strange comments at TSS. First i never said that WSRP is not being used, i placed a question mark on the headline. Here in germany this indicates a question, not a statement. As most of the comments in my blog indicate, there are producers which are bundled with products and projects around portals (something i knew before of course), but i searched for an online producer to test something. If the technology would be widespread, we would have this. Perhaps there are one or two of those, but i have not found them, despite expressive googling. On the contrary you find plenty SOAP webservices to play with. Why? Because SOAP is widespread and developed everywhere. The guy from Liferay (sorry cant see the name while replying) said that the technology might be too complex. As Liferay is a superb portal, i tend to believe him. Marc

Definitely! WKRP is way better (if you're in Cincinnati)!

We here at Liferay believe that WSRP is far too complex for the majority of applications, as we do with SOAP based services -- for a more robust and simpler to implement solution based on REST and can be easily "mashed" by other technologies: http://wiki.liferay.com/index.php/Simple_Remote_Portlets

Too complex for who? The container provider maybe but not for the developer.

We here at Liferay believe that WSRP is far too complex for the majority of applications, as we do with SOAP based services -- for a more robust and simpler to implement solution based on REST and can be easily "mashed" by other technologies:

Yeah, we made the same decision for now. Instead of implementing WSRP we currently have a generic web clipping portlet that can be used to integrate more or less any existing webapp as-is. We have used this both for integrating .Net, PHP and Java apps, and we have customers who hav written new apps specifically to be used with it. It is very convenient to just let people write apps "as usual" and then clip it into the frontend portal. An early version of this portlet was donated to portletbridge.org, which can be used with any portal (AFAIK).

We are using portletbridge -- any plans to further develop portletbridge?

We are using portletbridge -- any plans to further develop portletbridge?

We have developed our internal version a generation or so ahead, but I'm not involved with the portletbridge dev myself.

The Sun WSRP interop server is down right now, we are looking to setup a new WSRP interop server, meanwhile you could setup the binaries available at https://wsrp.dev.java.net to get a Producer/Consumer up.

We've been using a portal architecture based on remote portlets for about 7 years. Needless to say this was not using WSRP though. Benefits for us include: * Other organisational units can host their own portlets * Various programming languages used for portlets * Shared load * Flexibility in upgrading to new JVM (some nodes are still 1.4 others 1.5) * Eases portlet deployment issues I'd be more interested to know when WSRP 2.0 is going to arrive.

Yes, WSRP I would say is absolutely dead. I wrote about it here: http://francisshanahan.com/www/index.php/2007/wsrp-sooo-dead/