This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I saw in an answer to another question that you need a proper container to use portals/portlets. Are there specific application servers to use or just certain jars you need to have portals/portlets using Java?
Mike Firkser wrote:I saw in an answer to another question that you need a proper container to use portals/portlets. Are there specific application servers to use or just certain jars you need to have portals/portlets using Java?
The first thing you need is a good reason to use a portal architecture. Portals/portlets were all the rage for a while and many were implemented when simpler architecture would have been much more appropriate. The best scenario I have seen is when you have an assortment of applications that are somewhat related in their purpose, serving a coherent group, and that would benefit from centralized security/access control and maintenance. Of course, there's nothing wrong with implementing a simple portal/portlet project just for the experience and to give yourself something to base later decisions on. Take a look at Liferay or JBoss portal for a couple of free and open-source portal servers that are relatively easy to get up and running. Both are fully capable enterprise servers.
Portal infrastructure consists of:
- Portal server: aggregates content from different portlets to show a portal page. A portal page consists of multiple portlets (or windows you can say). You can think that portal server component sits on top of portlet container component.
- Portlet container: manages portlet lifecycle, just like servlet container manages lifecycle of Java servlets.
If you compare portlet container with a servlet container, then you'll find a lot of similarities between them. In most cases portal server and portlet container components are bundled together and built on top of an existing servlet container. In a way, the portlet container uses the existing features of servlet container to full-fill its responsibilities. The product vendor will usually specify the application servers on which their portlet server/container will work. For instance, Liferay comes bundled with JBoss, Tomcat, Jetty, and so on.
So, your understanding is correct, you do need proper infrastructure to use Java portlet components.
As we need a servlet container to run servlets/jsp, we need a portlet container to run the portlets. Portal is typically a wrapper web application that uses container and implements additional functionalities like UI console to manage the portlets (like adding,removing portlets on a page ...etc)
Pluto is one of the portlet containers (set of jars), that can be configured on existing servers like tomcat and then your tomcat turns into a Portal Server (Hope I am correct here)
Generally most of the open source portals are embedded in existing web/app servers like tomcat,geronimo..etc. Liferay portal is a good example. You can download liferay portal embedded in most of the servers.
A portal can also be a simple web application that can be deployed in any server.
The relation is : portlet (JSR168/286) > Portal (Liferay/WebspherePortal/JBOSS Portal) > portlet container (pluto container or any other implementations)
Joined: Aug 09, 2005
I should have refreshed the page, before posting
Joined: Nov 20, 2000
And I should have waited for sometime for you to post the answer