I am new to Portlets and despite having read some of the documentation on Portlets and the Portal Server, I am still unsure when this system should be used over, say, the Java Application Server, Servlets, JSP, etc. Could someone give some examples of the type of websites/applications that would use Portlets versus those that, whilst similar, wouldn't/shouldn't?
Thank you.
Well, firts of all, portlets are really only useful to provide portal channels with content. Standalone web applications that have nothing to do with a portal wouldn't need portlets.
This is purely a personal opinion, but using portlets is a major benefit to keep your portal channels modular. Changes to SUN's provider based channels using JSP's for example, can be a bit messy. Portlet applications run as separate web applications in the application server, and allow you to redeploy over and over again without much hassle.
In addition, making JSR168 compliant portlets keeps your channels portable, so you could migrate onto or off of SUN's portal server if you needed or wanted to.
Also, by using portlets, you can maintain the separation of business logic, in your portlet classes and their associated classes, from the display layout, which should be in your JSPs. In a JSPProvider based channel, the temptation is to put the business logic in the JSP. I know, I've done it. :) It is ultimately much harder to maintain the code when business logic ends up in the JSP files.
Finally, in Portal Server 6, there was no full-blown JSTL support. Using portlets made sure we could package the JSTL classes with the portlet application, so we were able to use JSTL in our portlet applications. This should not be an issue in PS 7 anymore, I believe.
Within portal server, using servlets is not really an option as far as I know, unless you wrap them inside a portlet. The portal desktop itself is a servlet. You can include servlets in your portlet application and then use include methods to use them in your portlet.
So when to use portlets?
- When you cannot use existing portal providers without heavy customization
- When your channel needs lots of supporting classes on its classpath
- When you want to keep your code portable
- When you want to re-use work already invested in existing servlets and other classes
When not to use portlets?
- When you're not creating portal channels
- When the portal server provides out-of-the-box channel providers that do exactly what you need
- When your back-end application provides portal integration, for example through WSRP, which the portal server understands.
All of the stuff above (except maybe for WSRP remote services) runs inside the Java Application Server of course. So you are not using portlets "over" the app server. The app server runs the portal, the servlets, the JSPs, the portlets, everything.
Hope this helps,
Erwin
Let me just add some basic about Portlet , Portlet Container and Web Container(Web Server , Application Server)
Portlets are deployed on Portlet Container which sit on top of Web Container.
Portlet Container gets bundle with Portal Server ex. Sun Portal Server(https://http://www.sun.com/download/index.jsp?cat=Portal%20Services& tab=3&subcat=Portal%20Server) and also as seperate entity such Open Source Portlet Container (https://portlet-container.dev.java.net).
Adding to what Erwin said , Portlets are not useful without Portal Server and In My view , Future trend of Portal Server will be Portlet Driven apart from basic Framework all the added features and customization should be using Portlets. Use of Portlet with JSR 168 specification(http://jcp.org/en/jsr/detail?id=168) allows you migrate them across Portal Servers and at any point of time If want to switch your Portal Server , this portlets will be usable as it or with minor changes.
Also with new Portlet specification JSR286 (http://jcp.org/en/jsr/detail?id=286), many new features are getting their way in Portlet development.
So Bottom Line , You should be using Portlet for adding your customization to Portal Server.
