Using WSRP for distributing load

One of the common gripes that I hear from portal customers is that it’s very expensive to scale portal. This can be true especially if the portlets suffer from ‘bloat’ and carry out more processing than they should. I know of one organisation here in the UK that was seriously considering abandoning WebSphere Portal to return to straightforward servlet development because of this.

So it was with great interest that I attended a presentation today by Andreas Brunnert from the Boebligen lab about the portlet container that’s now part of WAS 6.1 and, soon, WAS 7. This offers an interesting solution to the above problem. The portlet container in WAS could be used to distribute load from (expensive) portal servers to (inexpensive) application servers.

Another interesting consequence of having the portlet container in WAS is that stand-alone web applications can now be developed against the portlet API. That means that developers who don’t want portal can have their cake and eat it - all of the richness of Portlets’ state and context plus not having to worry about where the application will be deployed - portal, WSRP or stand-alone.

The portlet container in WAS also provides an interesting option for unit testing new portlets, at least partially. Maintaining developer workstations with the right level of WAS and WebSphere Portal is quite a challenge, and there’s always someone in the team who can’t compile this or that portlet. Having a WAS image and using the URL Addressibilty to access the test portlet would simplify the platform that the developers have to handle.

On a related note, I spent a very short time looking for a WSRP producer for .NET. I’ll have to ask my .NET colleagues but I wonder if wrappering .NET applications using WSRP might not be a way to handle migration and coexistence between the platforms.

Also note that portal is moving towards being a more “traditional” WebSphere Application (much in the way that, say, Process Server is). That’d be nice, too.