• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

portlet/portal understanding

 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All

I am newbie to portal/portlet world. Over the last few years I have been working on traditional J2EE web development using Servlets , JSP , EJB & also have used or have a fair idea about frameworks like Struts, webworks & Faces.
My understanding is frameworks like struts or jsf resolve some perennial problems with traditional j2ee web development.

With the introduction of portal/portlets, I reckon is a totally different approach towards web development so in some way or the other the portal/portlet architecture would be providing a superior effecient solution over traditional web development & would also incorporate solutions for problems resolved by frameorks like Struts, JSF etc.

Could some one ellaborate on the advantages of portal/portlet architecture over traditional web development using frameworks. Why would one consider portal/portlets over traditional web development.


Regards
Manish
 
Jason Moors
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me start by saying that my main experience comes from the SAP Netweaver portal which is a commerical portal which integrates will with SAP backend systems, but does not conform to the JSR-168 spec. Saying that I have experimented with Liferay, Jetspeed2 and Springbeans.

The advantage of portals and portlets over frameworks such as Struts / JSF is in the features that a portal provides as standard.

Most of the web applications frameworks you have mentioned aim to encourage application architectures based on the "Model 2" (Web MVC) approach, thereby enforcing a design pattern for writing applications, a provide some features like I18N and validation. I.e focused on the interface.

The main difference with the portal is that it provides common functionality require by enterprise applications - JAAS Authentication, Single Sign-On (typically via signed cookie), User Management and Role/Group based content and some portals go further by providing Content Managment and Collaboration, enabling users to share documents, use instant messaging etc.

The downside is that all this functionality comes at a cost in terms of speed and complexity, and from what I have seen of the open source Portals, they implement these features to different degrees.

I think the issue comes down to cost of ownership, whilst the portal JSR-168 spec means that you should be able to write a Portlet a run in any portal implementing the spec, in reality it means learning and maintaining another layer of complexity.

It basically comes down to your requirements, for my own applications, I haven't found the open source portals mature enough and my requirements haven't required the need for a full blown portal, so I've gone down the route of using the Spring framwork with security modules like Acegi Security.

regards

Jason
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic