Web Services for Remote Portlets in C# / .NET -- Options?

Question

I recently had my mind expanded by a new concept: Web Services for Remote Portlets, or WSRP. I learned of it during a presentation on a Java-based web portal we are considering purchasing at work; we are a .NET shop and WSRP would be the means by which we would extend this portal.

Although I cannot control the end decision as to whether or not we purchase the product, I can provide input as to how difficult it would be to build WSRP-compliant portlets. Unfortunately, my recent queries into the subject have turned up almost nill.

So I ask you, the SO community, the following: what libraries or frameworks are out there for building WSRP-compliant portlets in C#/.NET? What are some of the pros and cons of using WSRP in general?

Because there is no correct answer here, I will make this a community wiki post.

So far, I have only found the following:

• WSRP Toolkit for Sharepoint by Microsoft (but requiring Sharepoint).
• WSRP Portal and WSRP .NET Framework By NetUnity.

Given that WSRP is on top of SOAP, this seems like a perfect candidate for a WCF binding and channel, and yet I see nothing on the subject, anywhere.

Answer 1

If you read the WSRP spec carefully, you'll find it is a remote version of the Java Portlet Specification (if I'm spelling that right). That means that it's useful for integrating Java Portlets. Anything else will have to look like a Java Portlet, which is not very generic.

Answer 2

I think its popularity / adoption can be inferred by the fact that the last release from NetUnit was "This latest release adds support for Visual Studio 2005 and .NET 2.0."

Answer 3

WSRP is very contrarian. By now the world has seen that tight coupling between the data model and the presentation model is suboptimal. The success of RSS, REST, MVC, and web services in general shows this. Despite the WS in the name, WSRP stands against the core principles of Web services. The WSRP spec ignores the sound advice to keep data and presentation separate, and couples them tightly.

WSRP promises integration, at the UI level. This seems like the wrong problem to be solving.

It baffles me that this thing has lived as long as it has.
The problem it attempts to solve is often not the problem that should be solved.

Answer 4

I would have to agree with Cheeso. Integrating the UI with the Data only serves the portlet consumers and adds a big, unnecessary, risky layer to portlet producers. Our .NET shop has been recently forced to consider WSRP and I have found a lack of support and experience. The best MS-centric approach I have seen discussed is here. But I have not found any specific WCF implementation/support. Any leads greatly appreciated!

Answer 5

WSRP is essentially a portal-to-portlet web service standard. What is the primary data exchanged between portal and portlet? It's markup and largely because most portals use a web UI. This whole idea that it is not pure data versus UI is moot point. It's meant to be a web service for portlet discovery, meta data, markup, interactions, caching, portlet-to-portlet communication, etc. That's what a portal does even if not WSRP. WSRP however is an open, cross platform standard.

What is a portal that only integrates portlets from its own products and/or platform? Got Java-based PeopleSoft HR and would like to provide access to their portlets from SharePoint to your employees? Good luck. Why can't this be an achievable scenario for most enterprise software? And yes, I realize it is integration related to UI. That is one of the primary reason for why I'm using a portal. It's not like I'm expecting to get PeopleSoft integrated with SharePoint at the "pure" data level and somehow an Employee Benefits Web Part magically pops up in SharePoint ready for use. However, that is what I expect if the portlet-to-portlet integration is based on WSRP.

WSRP, although not perfect, is a superior solution in my opinion. Besides easy integration of portlet within a portal, it separates the portal from the application. No deploying of binaries to the portal server or even running on the same server. This makes sense. Never run applications on the same server as the portal server: neither will ever be upgraded. I've come to the conclusion that it's insane to put application binaries on the same server as the portal server. "Please deploy this application to the portal server and have it affect security, stability, performance, and everything in between and I would like create as many dependencies as possible and bring down the whole portal sever whenever I upgrade the application". It's a dependency nightmare. Better get a couple of portal vendor consultants to hold hands with when upgrading and to have someone to blame.

Do you need to load balance an entire portal platform when only a select number of portlets are hit the most? Portal vendors would like you to think so. A lot of the time, the portal is doing nothing more than waiting on portlets to finish processing. With WSRP, you have the flexibility to load balance portlets independently of the portal platform. It always breaks down to a few portlets that are hit the most. Why not load balance just those portlets? So instead of unnecessarily load balancing the portal on 80 CPU, you could load balance those few portlets on 10 CPUs. WSRP is also absolutely perfect for cloud computing.

WSRP is a portal-to-portlet standard. If you want to write a portlet that works in multiple portals and potentially across platforms, WSRP is it. If you are remotely contemplating integrating third party portlets, WSRP is it. It's the only standard. However, it also has some significant benefits over other proprietary local portal-to-portlet interfaces and should be considered for those benefits as well.