JSR 168 defined the contract between applications to be developed using portlets technology and the portal servers. But this technology somehow lagged behind in evolution and continued to exist with many challenges. During application technology stack selection, one comes across portal server options many times. Sometimes we have to choose between application server and portal server itself.
In this case you have few requirements which are pointing towards use of portal server, but it may be the case that you are not sure whether really there is a need of portal server. Recently Java introduced Glassfish Webspace Server and the technology space of portal servers seems to be becoming live again. In this article, we explore different important aspects of portal servers. It is assumed that you already know what are portal server, and also the difference between an application server and a portal server.
Some of the features that will attract you to select a portal server for deployment of your application are-
- Quality UI and Personalization: The application UI is simply zazy, containing many sections which can be collapsed, moved, modified in color or even removed from the page. Also, you want to design your own page with a glamorous look. Every day, you want the page to appear different. This can be the list of requirements which means a rich UI with heavy personalization is needed. On top of that, all these controls are in the hand of the user of the screen. This is when you need a portlet based application, because if you focus on building these features in your application programmatically, then the main focus of application development will shift from functionality to these additional features. You never want this to happen.
- Content Management: In previous point, the control was with the user of the screen, while in this feature the contents are controlled by the (content) administrator. They want to show organization’s hot products to the customers, in some advertisement space on page. Everyday you have something new to offer. There can be some space where you display organization’s news to your customers. In these cases, the content presentation need to be managed elegantly, while the developers are still focusing on contents, and not on the presentation.
- Information Sharing: Across different screens or screen sections, you want some information to be flowing smoothly. In short, the sections need to talk to each other on same screen or different screens. You can definitely program this, but if we add complexity of customization of this communication periodically, then it becomes nightmare. Portlet communication will help you in this case.
- Access Control: There are many patterns of security (authorization) implementations, you can hide screens, fields using security server (LDAP/DB/Tivoli) calls. You can write security custom tags or use off-the-shelf from frameworks like Acegi framework. But, when you have to apply security as a personalization tool with good UI to hundreds of sections, then this becomes a real challenge. Portal servers handle this very well.
- Workflow: I don’t know why this feature has been introduced in portal servers. There are dedicated business process management tools, but still few recent portal servers are offering these features. Ok, let us combine personalization, rich UI, better access control and work flow together, and you want to save money on this, then go for a portal server.
By this time, you must have become admirer of portal server, but wait there is other side of story. There are few challenges, which you must consider before finalizing on portlet technology. Here are those in detail –
- Standardization: Portlet technology is based on JSR 168. Vendors of portal server need to comply with this specification, but it is not the case with many servers. Portlets are developed using the APIs offered by a vendor. This binds the portlets with vendors. Now, if that vendor is following this specification religiously (i.e. confirming compliance with it), then we can migrate our application to another portal server which does the same, otherwise there is an issue. The reason why some of the vendors do not follow this specification is because JSR 168 does not contain all features that a portal server requires.
- Performance: Portlet container runs in web container. This is a two step process as compared to a simple application running in web container. This might lead to performance problems in portlets.
- Portability: There are two aspects to this – first is portal server to portal server portability, and second is portal server to application server portability. Second option is eliminated completely as it will involve huge cost, because portlets are developed based on APIs provided by the vendor. First portability option is discussed in ‘standardization’ point above.
- Custom UI Development: Portlet based page is mostly based on themes and skins (look and feel templates), you require very good expertise in web designing to come up with themes and skins that suite your page. This might be a good challenge for developers.
- Different Application Development Cycle: Portlet based application involves development as well as customization and configuration in portal server. Hence the normal application development (which may involve writing the application and then bundling to deploy a .war or an .ear file) on application server may not suite here. You need to plan differently for portlet applications.
- Cost: Portlet servers are very costly. Hence there is always choice whether you want to custom develop the required features or go for portal server. If features are not complex and too many then you can think of custom development.
When to go for Portal Servers?
Based on above discussion if we want to extract those points, based on which we can select a portal server as your application’s host, then here is a list –
- Strong Personalization Needs
- Performance is Not a Big Issue
- Portability is Not Required
- Good UI Expertise
- Ample of money
When to say no to a Portal Servers?
Following points will be drivers when you want to say no to a portal server. Definitely cost is an important point, but in addition to cost these points can help you to select custom development over a portal server.
- Just Rich UI with Simple Personalization
- Product that can be ported on any application/portal server
Portal Server Options:
There are many portal server vendors in market for both Java and .Net technologies. Below is the list of some of the servers, that are primarily sharing this market. Sun has recently brought GlassFish Webspace server in this race.
- IBM Websphere
- Sun – GlassFish