Time To Discusss WSRP…


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.


Comments (27)

  1. Todd Bleeker says:

    Hear, hear! Nicely said Fitz. WSRP is really hot right now.

    In the last month I’ve actively discussed these concepts with at least two customers. The first has a non-SharePoint portal and was motivated by the quick reuse of IFRAME-ing an ASPX page (both UI and code-behind/beside) in both portal products. They have many ASPX developers, feel comfortable with this infrastructure, like the fact that the solution (page) can be tested apart from SharePoint, and will likely pursue this option. The other customer was keenly interested to understand what WSRP was all about.

    Also recently, I have been coding AJAX “shell” Web Parts using out-of-band AJAX-like (or eventually ATLAS) calls to a self-contained Web Services layer. I like this because I don’t have the postback and state management required in a traditional Web Part which is critical to the success of my application. Also, everything the Web Part is dependant upon is entirely contained within the Web Part’s deployment CAB (wppackage).

    However, one of the reasons the aforementioned customer wanted to use ASPX pages rather than Web Services (ASMX) had to do with the location of the UI code. Traditionally this customer generates their UI in an ASPX page containing server controls or user controls (ASCX) calling business logic in a component (code-behind/beside, ASMX, COM+, etc.). In Web Parts, we traditionally generate the UI from within a WebPart class using server controls or user controls (ASCX) and call business logic in a component (Web Part assembly, ASMX, COM+, etc.)

    But in the WSRP model you describe and in AJAX “shell” Web Parts, the UI can often come directly from the Web Service (ASMX) itself. The Web Part effectively becomes a placeholder (DIV) that the user can position on any Web Part page. It knows how to load the UI it receives from the Web Service into its innerHTML attribute. This way, each portal need not have UI logic to consistently recreate that UI. Since you mentioned consuming the XML from within the DVWP I realize that isn’t necessarily an accurate depiction of your post but humor me…

    My question is this, which is inherently better design?

     1) Using an IFRAME within a Web Part to host an ASPX page.

     2) Using the Web Part’s own DIV as the placeholder for HTML returned from a Web Service (ASMX) call.

    For the sake of argument, let’s assume that either could be dynamically changed without a full Page postback and that the hosted UI (ASPX and ASMX) are provided in another Web Site, excluded managed path, or embedded as a Web Part class resource (my preference).

    These two approaches achieve the same goal but are architecturally very different. I’m certain that the pros and cons go much deeper than the points I’ve make in this comment. Does WSRP favor one over the other?

    At any rate, we’ve got a whole new breed of .NET Framework 1.1 SharePoint Web Parts running on our SPPT 2003 platform to contend with.

    <Todd />

  2. Shane Perran says:

    Interesting post (and topic) Mike – definately a good read.

  3. Mike Fitzmaurice posted something about wsrp. Post it here so that I can find it later…

  4. WSRP, the name itself says that Web Services for Remote Portlets. The scenario 2, the quick reuse, where one portlet just clips the content from the  other portlet is not really a candidate for WSRP. One can use a simple web-clipping portlet for achieving the same, without the overheads.

  5. FitzBlog says:

    WSRP, as I covered a few days ago,&amp;nbsp;is an interoperability standard.&amp;nbsp; It&amp;rsquo;s platform- and…

  6. MyNameHere says:

    "Technology’s full potential can be realized only when customers are able to securely deploy solutions, and the entire community works in partnership to foil attacks by hackers and criminals."

    A browser should support:

    a rational, reliable, stable object model per standards (I find IE’s "proprietary" extensions

    less of an issue given their documentation vis-a-vis FF’s legacy drag)

    a *native* dom/xslt in-core data management model

    a *native* xmlhttp transport

    a *native* cryptographic service provider (along the lines of easily establishing a

    "secure" conversation, easily encrypting/signing upstream content)

    When the basics are in place, the "thorny" issues remain: memory/state management,

    cross-domain integration (uh, no – not wsrp), the "last 2 feet".

    The market won’t be taken by the "tabbed" view audience, or graphic designer eye-candy

  7. In my experience, people interested in portals can be roughly divided into two groups. One of those groups…

  8. Curt Smith says:

    I’m the weblogic portal guy, another group is developing a .NET 2.0 application.  I need to expose that app to the public via the portal and SSO.

    WSRP is the perfect solution.  

    I don’t know what a sharepoint server is, but I imagined MS implementing WSRP producer as an add on to IIS, were a virtual server would be exposed as an WSRP producer, thus be highly transparent to the served application.

    Of course my need is today so this project won’t due.

    http://www.netunitysoftware.com/e/ may be a solution.  

    Or http://portletbridge.org/ a proxy portlet is my best chance of this working, short of an IFRAME portlet (ugh!).  

    tnx for any ideas,  curt

  9. Mishimas says:

    WSRP seems to be really nice. I have a question, is it possible to use WSRP to have a simple web application, not a portal application, consume the html fragments generated by a portlet producer ? We would like to display in an i-frame the content of a JSR-168 portlet deployed in a distant server. Is there a Java library to do that ? If we must implement a WSRP consumer for java in iframes does it take many times ?

  10. As more and more companies get past the pilot stage with their SharePoint 2007 deployments and start

  11. As more and more companies get past the pilot stage with their SharePoint 2007 deployments and start

  12. Yesterday, I had lunch with Fitz AKA Mike Fitzmaurice. Fitz is probably one of the most recognizable

Skip to main content