The Rise of the Portlet Containers

So now that the Portlet 2.0 spec is approved, it is very interesting to watch the evolution of the OSS market since the Portlet 1.0 spec.

The most noticeable change is the projectization of the portlet container technology. (I will not use the word productization because some of the projects release a complete product and some just make a dump of the source code of the project).  4 years ago the only standalone portlet container was Pluto (the Reference Implementation) and today there is an avalanche of at least 4 portlet container projects (including our JBoss Portlet Container product).

So the question is why do we have so many open source portlet container projects ? because a portlet container is an important piece of a portal and every one wants to develop its own portlet container ?

I think it answers partially the question. If you look a bit more closer at the portlet container technology, then you will see that there is an obvious lack of standard for embedding a portlet container in a portal, i.e a portal needs to chose a portlet container and use its proprietary API to interact with the container. Indeed the portlet specification does not specify that contract because this is the scope of the WSRP spec. As of today if a portal wants to reuse a portlet container in a portable manner, that portal needs to talk WSRP and nobody wants to do that!

So the rationalization of the market could drive to the adoption of a portal spec. It would provide the minimum basis to create a "Portal" profile in Java EE (which is today an hot topic!). Without a portal spec, I don't see any chance to have the portlet container technology part of Java EE.