I thought I’d start this next wave of postings with the subject I’ve avoided the longest — WSRP.  This one will be a little long…

What Is WSRP?

The abbreviation stands for Web Services for Remote Portlets.  There are plenty of details, but in essence, WSRP defines how to use SOAP to request and receive blocks of HTML (as opposed to making a method request and getting back XML data, which is what we usually request/receive using SOAP).  It’s defined by an OASIS committee, whose site URL is http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp.  Microsoft is a member. 

What Isn’t WSRP?

WSRP is not magic.  It’s also not a shortcut to good application design.  And only if circumstances align in exactly the right pattern does it save time and money.  We’ve been struggling with how to talk about WSRP for some time.  We’re perfectly happy to support it — Microsoft loves Web services and interoperability standards, and WSRP is both of these.  We’re not, however, especially eager to promote it — at least not the same way some (but by no means all) of “the other guys” have done.  Like any tool, it’s good for some things and not so good for others…

Why Ask For WSRP?

Generally, three hypothetical reasons come to mind:

1. A customer has put together a request for proposals, and want submissions to support as many standards as possible for risk-reduction reasons.  They haven’t considered whether they’d actually make use of it, but standards are generally good things to support.  Let’s call this the “checkbox” motivation.

2. A customer has one portal product onsite and wants to buy another one.  They don’t want to rewrite all of their portlets for the new platform.  Being able to reuse a portlet in two places is attractive.  In fact, let’s take it one step further, as some WSRP proponents have done, and say that the customer has a preexisting Web applciation (not porlets at all) and they want to surface pieces of it inside their newly-purchased portal product.  Let’s call this the “quick reuse” motivation.

3. A customer provisions a great many sites on a shared Web farm, and doesn’t want to support installing custom portlet code in that shared environment.  Being able to run the portlet on some extra middle tier, and just redisplay the results on their production portal machines, is very attractive.  Let’s call this the “remoting” motivation.

How Good An Idea Is This?

1. Checkbox Motivation:  Not a good idea at all.  This is knee-jerk blindness.  If you truly need a standard, of course you should demand support for it.  But if it’s not going to help you solve a legitimate need, no one is served by demanding this.

2. Quick Reuse Motivation:  Reuse is good, but the devil is always in the details.  Most of the proponents of WSRP describe scenarios like what I’ve drawn here:

Portal-to-Portal Crosstalk-o-rama

(Hey, it’s a blog, not a formal publication.  Clippings of quick Tablet PC sketches just seemed like the right thing to do...)

It took time to develop the portlet running in Portal 1 here, and since Portal 2 isn’t from the same vendor, it’s attractive to have Portal 1 expose that portlet as a WSRP producer Web service that Portal 2 can consume and display.  Sometimes, the producer isn’t even a portlet running in a portal product.  It’s some code that’s been added to encapsulate an entire page-based application so it can be displayed elsewhere as a portlet — essentially doing IFRAME-ing via SOAP.

Now is the time to make sure everyone has started assessing this in the light of a Service Oriented Architecture (SOA), something every major player in the industry has been advocating for over a decade when we started talking about three-tier application design, etc.  At a minimum, you should split the user interface, the business logic, and the data retrieval into three parts.

If you did the right thing in the first place and coded most of your functionality into a “traditional” Web service and hosted it on a middle tier server, the incremental cost of creating a quick portlet UI for interacting with it is trivial.  The fact that you have vendor-specific portlets is no big deal.  It looks like this: 

Two portlets from two different portals, each calling the same Web service

Heck, FrontPage can, in a minute or so, generate a dataview Web Part that calls/displays Web service activity.  I’m sure some of “the other guys” have quick generators for Web service-coupled portlets as well.  And if you can wait until later this year, the Business Data Catalog that’s coming in Office “12” servers will eliminate the need to write any Web Part code in many scenarios (I’ll blog on this subject after I’m done with this one).

What’s more, making sure you offload most of your work to a middle tier Just Makes Sense.  What if you want to reuse that logic in a non-portal application?  An integration/orchestration server like BizTalk Server, WebMethods, etc.?  What if you want to use it in a standalone Web application?  Portlets are user interface components; they should not become substitutes for Web services that execute business rules and retrieve information.

“Heavy” portlets weighed down with a lot of code are not often a good idea.  The motiviation to reuse them increases as the portlets get “heavier”.  Reusing heavy portlets is compounding the problem — and two wrongs do not make a right.

Reuse works when we code for reusability.  It takes planning and time to architect and code for reuse.  It’s not magic.

What’s more, the approach used in my first drawing has the potential for two big unpleasant side effects:  network traffic and licensing.  Most application server environments are optimized around passing traffic from the browser to the Web server to the app server to the data and back.  What happens when you have multiple farms of Web servers suddenly making frequent side-to-side callouts to each other in order to render pages?  It introduces bottlenecks that have to be addressed by entirely new load-balancing logic and resources.  Moreover, given that your portlet is running in a portal product, and its use has suddenly widened in scope to more users, you might find yourself paying more in Portal 1 license fees for all of the new traffic/usage that Portal 2 brings in.

But I’m not bashing WSRP itself; Microsoft certainly isn’t (it wouldn’t sit on the committee if it hated the standard).  I’m bashing bad design, bad design often espoused by some of WSRP’s more vocal proponents. Actually, there is a way to implement WSRP that is anything but crazy, and focuses on reuse in a way that works as part of an SOA.  So, while still thinking about resuse, let’s bring in the…

3. Remoting Motivation:  Remoting is a very nice idea.  I can understand this one completely in several cases.  So let’s, depending on your point of view, either add a new tier to our SOA or split the UI tier into two parts.  In other words, this:

WSRP as part of a SOA

The portals are responsible for final UI rendering, but there’s now a UI staging tier that’s handled by a WSRP producer server.  Now we’re cooking with gas.  Requests/responses travel up/down the optimized path, and the thing serving up the portlet is a Web service application server.  Any portal product that has a general-purpose WSRP consumer (which we will have in the box with Office “12”) can make use of that Web service.  You should still put most of the logic in the “traditional” Web service so it can be reused by non-portal applications.

This approach doesn’t hide the fact that a WSRP producer is a Web service.  In fact, it embraces it.  And while my opinion is admittedly pro-Microsoft, and I dare you to find a platform more conducive to building and using Web services than .NET, if you want to do this using Java, go for it.

We put an example of this (mainly to show it can be done than to serve as a best practice example) on GotDotNet, but if you’re looking for a commercial effort that helps you quickly generate WSRP producer Web services,  it’s worth mentioning our friends at NetUnity Software (www.netunitysoftware.com).  They have libraries, Visual Studio add-ins, and deployment tools for quickly authoring and deploying .NET-based WSRP producer Web services that can be consumed by any bona finde WSRP consumer.  It’s almost always cheaper to deploy these kinds of producers than taking an approach that presses existing portal products into service as WSRP producer servers.

So, Should We Just Stop Writing Web Parts and Switch to Creating WSRP Portlets Using This Last Approach?

Of course not.  Well, sometimes we might want to do so, but the line of reasoning to apply here is the same line of reasoning to apply when deciding whether to write a .NET assembly or a Web service.  Locally-running code is usually faster than a remotely-called Web service.  Locally-running code in the form of a Web Part has access to more information about the server in which it’s running, as well as the page and site to which it’s been added, as well as the other Web Parts on the page (using Web Part connections — although version 2.0 of the WSRP specification is supposed to provide something for this).  Deploying locally-running code to all servers in a farm can be annoying, but if you’re load-balancing that middle tier, it’s the same amount of work, and WSS “v3” will provide better tools to deploy custom code to entire server farms.  They require less infrastructure.

Whatever you do, don’t skip the step where you encapsulate business logic in a “normal” Web service.  You’ll get real reuse by doing so, and it will make the job of coding “normal” Web Parts or WSRP producers all the more easy.

It all comes down to developer productivity, ease of deployment, ease of maintenance, ease of reuse, etc.  The devil’s in the details.  It’s up to you to decide, but please, please, please make that decision an informed one.