Sorting out WSRP, JSR168 and Web parts

I’ve noticed a lot of confusion and misunderstandings around these portlet ”standards”. This posting aims to sort things out on a fairly high level of understanding by reasoning around the strengths and weaknesses and suggesting some best practices.

So, what is WSRP?

The abbreviation stands for Web Services for Remote Portlets, and the key word here is “Remote”. It is now a fairly old standard, version 1 came 2003 and version 2 is still in draft although many portal vendoers have already made their own implementations of the not-decided version 2. The standardisation work is run in an OASIS committe’ (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp).

WSRP basically defines how to use SOAP to request and retrieve blocks of HTML, instead of XML as regular web services does. This means that the WSRP portlet runs on a one web server and can appear in one or many web portals running on other web servers by sending HTML-code to these web portals. WSRP portlets can be written in any programming language. Before getting into the reasoning around when to use WSRP, we need to sort out the two “non-remote” portlet specs, JSR168 and Web parts.

Comparing JSR 168 portlets with Web parts

JSR 168 is a standard for coding portlets in Java. It consists of a set of class definitions to be installed on portal products supporting JSR168.

To compare apples with apples, JSR168 competes with Web Parts. WSRP is a completely other kind of fruit. Both can support WSRP. These are the most important points of comparison between Web parts and JSR 168:

• Language : JSR168 portlets can only be developed in Java. No other language works. Web Parts can on the contrary be developed in any language supporting .NET, which at least in theory includes Java/J++…
• Support for different portal plattforms : JSR168 portlets can, at least in theory, be codes once, and run in any os the JSR168-compliant portal produkcts out there. In reality, it is very easy in the Java development tools for each portal product, include product-specific class libraries breaking the standard. Using them makes You tied to a proprietary portal product anyway. In any case, every portlet needs careful testing and debugging when porting from one portal product to another. I personally think that the JSR168 in reality provide very little value from a standardization och reuse point of view. Web Parts makes no secret it’s a proprietary technology and Microsoft makes the most of that freedom not having to compromise in standards committees. Web parts is therefore a superior portlet technology to the JSR168 implementations.
• Support for different environments : JSR168 portlets are just portlets. They only execute in the context of at portal product. Web Parts runs in MOSS/Sharepoint Portal, in Windows as Win32-apps as well as in so called Smart clients for handheld devices.
• Consuming WSRP : Some portal products have built-in WSRP support while others goes through a JSR168 portlet. Microsoft takes that road by offering at out-of-the box WSRP consumer Web part.
• Producing WSRP-portlets : Most JSR168-portal products includes code to emit JSR168-portlets as WSRP. Microsoft haven’t built in WSRP produces support in MOSS 2007, but 3rd-party solutions from NetUnity Software supplies tool to develop WSRP producer portlets on the .NET platform.

This is a simple architecture for JSR168/Web parts portlet applications:

When to use WSRP portlets?

Scenarios motivating use of WSRP are:

• From a host / web server deliver portlets as presentation oriented web services to be included in aggregating web porta application. On such host can cater for many web apps.
• Web portal apps consuming and in a portal framework integrates presentation oriented web services delivered by internal and external WSRP suppliers.

The WSRP-specification says nothing about the implementation of the portlet, it defines its interface. This is where WSRP connects to Java's portlet specification, JSR 168, and Microsoft’s Web parts. WSRP is not a competing technology, it’s more like complementary. JSR 168/Web parts are used to define the portlet whereas WSRP is used to define the portlets appearance in a remote portlet container (like a web portal app).

Experiences of WSRP

WSRP has some limitations when it comes to complex web applications with advanced user interfaces (interactivity, design). These limitations are:

• Separation and handling of presentation/design and the use of Cascading Style Sheets.
• Handling of DOCTYPE making accessibility /WAI-adoption harder
• A WSRP-portlet knows nothing about its content. The content and design of a WSRP portlet may look different from the rest of the web page it is appearing in.

How to think

If You have a ”pure” Java or .NET –miljö without any needs to remotely distribute portlets, then You develop directly in JSR168 or Web parts. No need for WSRP.

The advantages of WSRP are obvious, it can easily be used in any portal application without local installation, but what are the downsides?

• Consider if You can live with the limitations described above.
• The extra development work to add the WSRP-interface to Your portletspå dina portlets.
• Code running locally (JSR168 and Web parts) generally runs faster than remotely run code. There is overhead in the Web service calls.
• Code running locally has access to more information about the execution environment, both the hardware to execute on and the web page to appear in. Using that information, the portlet can act smarter. Communication with other portlets are easier if you know what other portlets that surrounds You.

One smart way of setting up a WSRP-enabled system architecture is to use a “portal UI staging tier”:

The plan here is to develop WSRP producer portlets either in in Java or .NET. Render them in a web portal application using a thin layer of portal specific code (for instance a JSR168 or Web part). This is a SOA-friendly architecture, easy to deploy and modify, that also scales well.

© Copyright 2007, Tomas Elfving