When the JSR168 effort was started, its primary goal was to offer a standard programming model, and avoid proliferation of proprietary programming models for creating portlets. This JSR almost achived these goals when the first version of the Portlet API specification was released two years ago. But it is now at the verge of getting fragmented. I think it is time to take notice.
When I was asked to serve as a member of the expert group for JSR168 representing BEA, I was excited about it. I liked the proposed programming model for portlets. It was simple, and abstracted the main concepts (such as the two phase life cycle) very well. Most importantly, it helped influence the Web Services for Remote Portlets (WSRP) 1.0 specification. The WSRP technical committee at OASIS tried to keep a close mapping between the programming model in Java, and its view across the wire in WSRP. Today, portlet API implementations from some portal vendors let you consume those portlets remotely using WSRP.
All this was two years ago. What happened since then? Nothing. Everything other than JSR168 evolved. WSRP is making progress towards the next version. If things go as planned, WSRP 2.0 would reach the Committee Draft status this year, and be an OASIS standard early next year. In the Java world, Struts and Java Server Faces have gained more popularity and acceptance. The use of portlets to build composite web user interfaces has also become popular. But the Portlet API remained the same. It still looks and feels like the Servlet 1.0 specification with no provision for taking advantage of newer standards and frameworks, and support for more sophisticated use cases.
What is wrong with JSR168 today? Here are my gripes.
Poor Controller
The basic portlet interface is simple to use, but building a complex flow could be painful. Imagine implementing a Java Pet Store like application as a portlet. Unlike a servlet, a portlet is supposed to be self-contained. It is expected to wrap an entire application including its view, the flow to navigate the view, and some amount of business logic. Doing all the controller work in the processAction method of a portlet means cluttering your code with complex if/else blocks. This API needs the support of a modern MVC framework to manage the controller tasks and the flow. But this is currently missing.
There is an alternative. Right now, some commercial portal frameworks like WebLogic Portal (and I believe some others too) allow applications built using Struts and Page Flows be aggregated as portlets into portals. However, there is a problem with this approach. Since such support usually involves replacing or plugging into the controller framework and URL rewriting, there is no guarantee that the same Struts application deployed on two different portal frameworks works exactly the same. One solution is to let frameworks like Struts and Page Flows rely on JSR168 to get aggregated into portals. This way, tasks like URL rewriting can be mapped to a standard API, thus guaranteeing consistency and portability. In this apprroach, a generic portlet written to comply to JSR168 can be used to deploy Struts and Page Flow applications as portlets. But to get this right, such frameworks need to comply to the portlet lifecycle, and expose features like modes, window states and portlet preferences to those Struts or Page Flow applications.
Support Java Server Faces
There needs to be a standard support for using Java Server Faces within portlets. This is quite natural since JSF provides something that the Portlet API is lacking. Sun has a JSF-JSR168 bridge. But since both these specs were developed under the JCP banner, the bridging effort also should take place within the JCP. This way, portlet developers can expect a consistent behavior across any JSF and portlet API implementations.
Fragmentation
This is my biggest concern. The first version of the portlet API addressed some of the very basic use cases, such as the two phase model for processing interactions and rendering the portlet, modes and window states, portlet preferences etc. But those are not enough to build useful portlets and portals. For example, most portal frameworks provide some kind of interportlet communication to let portlets coordinate some tasks and provide richer user experience. Currently WSRP 2.0 is adding support for an event-based coordination model to solve this problem. This model is designed such that portlets can communicate with each other via events without getting strongly coupled. The next version of the portlet API, if and when it gets standardized, should offer an equivalent feature in Java. There are several other features that portlet developers need. In the absence of any effort for advancing the current standard, most vendors will likely add some proprietary extensions for events and other features. This is not the best thing that can happen to a JCP specification.
Don’t ask me why there is no effort towards advancing this API. I have no idea.
Disclaimer: I work for BEA, but these opinions are completely mine.
Update: About three months after I posted this entry, JSR286 effort was started. This JSR is now making good progress.
{ 1 comment… read it below or add one }
Subbu,
I read your article with very keen interest. I believe I was in my final Year of Engineering graduation, when this JSR 168 specification is released. At that time, I Was very ignorant about the portlets, except the known fact that, “A portlet is kind of servlet”. The topic i.e. discussed here is little bit way beyond my imagination and understanding, even since; I was working on weblogic portals for the past 13 months.
Developing portal applications with framework like weblogic (and some other) is an easy work. We developed a complex web application (2 page flows, more than 35 jsp pages and 2 web services) on Weblogic Portal (one portlet Total application). The difficulty level to develop the application with the framework support is so simple, it is matter of drag and drop the controller (Develop the views, implement the navigation flow and business logic) on the respective portlet. But, to implement the same in the basic portlet interface, It would have been so frustrating and tiresome. And it is even foolish to implement everything under one method processAction. Ofcourse, it is not guaranteed, that application developed in one framework, works in another.
Anyway, most of the frameworks have implemented portlet specification in their own way, they have given the portlets the MVC support to manage the controller tasks, the navigational flow and business logic and the same happened with the interportlet communications too. And in future most other features will also be implemented in a proprietary way.(The same happened to the Servlets API. No advancement has been made in API to support the controller tasks and navigations, which helped the open source frameworks to pop up to handle these tasks)
Why is that, a Java equivalent API is needed for the portlet API for interportlet communication?(as frameworks have already implemented it)
In fragmentation, you once said, “There are several other features that portlet developers need“. May I know, what are those? I am really not aware of it.
Please pardon me, if my questions are out of scope.
Cheers,
Kumar Reddy.