Delivering presentation over Web Services with WSRP

I recently was asked to talk about the possibilities of implementing a WSRP consumer on the .NET platform. And suprisingly, it has very little to do with Web Services Routing Protocol.

"Web Services for Remote Portlets" is the OASIS specification name and it's all about delivering presentation instead of data over web services. At first the thought of delivering html over WS sounded weird to me. Isn't this just like screenscraping. And secondly, aren't "Portlets" strictly a Java thing?

Well, no and no. The specification uses the term portlet, but is completely based on common standards like XML, WSDL, UDDI and Schema. Java did have an advantage though, as the JSR 168 specification was developed in close cooperation with WSRP. So, by now you've probably guessed what it does: WSRP allows you to publish a local portlet remotely with web services. This means that a user in a portal could have a portlet that is running on another portal directly accessible in his view.When delivering data over webservices you are always dependant on some kind of receiving transformation to make it availible for end users. Some services are only meant for presentation and should be delivered this way.

I have had this post on hold for a while because I felt iffy about the whole concept of doing synchronous calls on web services to deliver presentation. What more does it really do than deliver wrapped html?

First and foremost the advantage of WSRP is that it delivers presentation in a _standardized_ way. The services can be discovered, and they have metadata. They have standard ways to perform pageflow and they have ways of doing URL-mapping and handle state. If the standard gets broadly adopted in both camps (J2EE/.NET) service providers can deliver functionality to customers portals really quick as each user can implement the service in their portal view without doing any development or deployment at all. Web shops can deliver orderforms and detailed catalogs to resellers, and media can deliver readily formatted, personalized content with interaction functionality directly in an end-users portal view.

To make this more than a "java thing" it needs Sharepoint support. There are two aspects to this. ASP.NET WebParts (not only for Sharepoint after Whidbey) must be enabeled to act as WSRP producers. In other words, their content will be consumable by any other portal that supports WSRP. Secondly a WebPart must be able to act as a WSRP consumer, it must show the presentation delivered by a WSRP producer. Developing the consumer part for .NET is probably not that hard, but to deliver the seamless "automagic" producer side of the story is quite a challenge. It will be interesting to follow the .NET community on this subject.

This sounds like it needs Microsoft backing, and Redmond just joined the OASIS WSRP Committee. However there are no trace of an indication from Microsoft on the subject. One might speculate that Microsoft would not want to support this standard because it will allow "heavier" portal services to be hosted on Java, and Sharepoint will remain a presentation/collaboration oriented "lightweight" tool. Also the concept of delivering presentation over ws contradicts (not only) Microsofts strategy on datadriven webservices (BizTalk etc.). I haven't quite decided for myself yet either.