Saturday, October 15, 2005

Portlet technology rant

Now time for a little portlet whinge, it is long overdue...

Nobody is perfect and it is all too easy to criticise. There is something about the JSR168 portlet architecture that strikes me as a giant leap backwards. Maybe it is concept of modes (View, Edit, Help) that reminds me of my early days as a Perl programmer where a single script would deliver all the application pages. At least at first glance the portlet architecure appears to have little similarity with the much admired MVC architecture. JSR168 portlet development with all these different competing scopes existing in parallel is very confusing even for an experienced J2EE developer.

Best practices for portlet development have yet to be properly established. With the current absence of something like a portlet aware JSTL it makes current J2EE best practices difficult to translate into the portlet development arena.

This current void in the portlet technology stack is an opportunity for unscrupulous purveyors of MVC solutions and such to tout their wares as the missing pieces. I am a great admirer of Craig McClanahan's work but I have yet to see why JSF is better than Struts. This probably makes me a non-believer but if I was to choose a new framework technology to learn more about it is much more likely I would choose Spring rather than JSF. The likes of Sun's JSF are likely to benefit as Sun are shoehorning it into portlet creation wizards such as in their Java Studio Creator 2. I don't want to cast aspersions but I would also expect Oracle to take advantage of the confusion surrounding portlets by integrating JSF and their JSF extension ADF, into their portlet factory software.

Don't get me wrong, I'm sure that Sun, Oracle, IBM, Novell and all the other technologies that creep into my portlet applications by stealth will stand or fall on their own merits. However, call me old fashioned but I'd like to do the choosing of which technology I integrate into my portlets and this is why projects like Apache's Portals Bridge will be so important to make the connection between existing J2EE best practice and future portlet best practice.'s out of my system, I feel better now.


Mark McLaren said...

agreed - we developed some complex portlets for Websphere Portal and got the fright of our lives and vowed never to develop portlets again.
Note: Comment imported. Original by Anonymous at 2005-10-15 18:02

Mark McLaren said...

You may also want to take a look at things like the PortletBridge ( which would allow you to continue build apps the way you always did, and then simply link them into portals. The next step after that is to start exposing apps using WSRP, and with a generic app2WSRP bridge on the producer side (using techniques similar to what PortletBridge does on the consumer side) that would mean that you can even write your stuff in PHP or ASP or whatever.
Note: Comment imported. Original by Rickard at 2005-10-16 12:17

Mark McLaren said...

Prior to portlet concept, web-development was like build DOS apps where everybody spent too much time on UI & config aspects and where no-application could interact with each other. Portlet is a young tech but it's the way the thing will be developed: IBM, Bea, Oracle, Sun and MS (take a look to WebPart on ASP.NET 2.0) say that.
Note: Comment imported. Original by Diego at 2005-11-01 16:35

Mark McLaren said...

I don't agree that prior to Portlets everything was poorly architected and standards were non-existent.

Web services technology (SOAP, XML-RPC et al) were long established methods for cross platform communication.

The Struts framework for example existed way before the portlet spec and in many ways was arguably architectural superior to JSR168 portlet standard. If I choose not to use vendor specific portlet wizards I actually expect to have to spend *more* time on UI & config aspects when implementing portlets than I did for web applications.

I feel I need to put the record straight about this and say that I understand, applaud and sympathise with the goals of the JSR168 project. A cross portal platform, vendor independent standard is a most amiable mission. My gripe is purely based on my early experiences of actually trying to create portlets using the Pluto implementation of the new technology standard. The portlet standard doesn't feel clever or natural to me in the same way as things like Struts or JSP/servlet programming do. I am fully aware that in writing to the portlet standard I am "doing the right thing". IMHO JSR168 is a very awkward standard to use. When I'm implementing some code that feels hideously complicated in order to render a simple page in a portal it is really difficult to convince myself that it the right thing to do (let alone try and convince other non-portal developers to develop portlet versions of their applications in order to work inside my portal)!

Note: Comment imported. Original by Anonymous at 2005-11-02 15:25

Mark McLaren said...

Sorry but I think I been misunderstood.

With 'traditional' web framework (from J2EE to Structs, Spring, etc.) you can build SOME customer applications but it's unreal to develop ALL customer IT infrastructure. So what you need is a 'portal' that embraces all applications enforcing them to same UI and enable integration 'at-the-glass' (like click-2-action on IBM WPS or connections on MS Sharepoint).

Ciao, Diego
Note: Comment imported. Original by Diego at 2005-11-03 22:45