When I think of a web portal I think of a framework for creating web applications. Depending on the vendor, this framework comes with number of different capabilities and tools out of the box and varying degrees of constraints to use these tools. For example it can come with web content management, work flow driven content management, dynamic customisation, dynamic personalisation, dynamic security, auditing, analytics, staging, performance monitoring, searching, ability to integrate other web app’s, ability to integrate with other enterprise app's via standard protocols such as JSR170, SOAP/HTTP, WSRP etc…
On top of the above mentioned capabilities portal vendor will also provide integration and or basic out of the box capability for the latest collaboration tools wikis, discussions, announcements, chats etc…
It comes with a lot of “free” stuff. But as we all know there is never a “free lunch”. There is always a trade-off and in this case it will be in the portal learning curve, added overhead (non-required features, memory, administration), some technical constraint (library dependencies, platform etc…) and possibly performance (again depends on the vendor). Every web application is different and each case will require business requirement analysis, technology investigation and justification of the decision to use or not use a portal for a particular web application.
Generally speaking portals will provide most benefits for:
- Modular application development (using portlets)
- Applications requiring features that are provided out of the box by a portal (cms, templating, role based access, collaboration tools etc…)
- Applications that integrate other web or non-web applications and present common look and feel
So now you are ready to stand up a portal as pure content site, mash up site a wiki server, blog server, document library, collaboration server etc...
But what if you need custom functionality? Let’s look at some of the technology choices that need to be made.
Technology
Broadly speaking web applications run on a technology stack. Anything non trivial that needs more than a stand-alone web server will require a servlet container or an application server (on Java platform).
Technically, portal is a technology layer that sits in between one or many web apps (portal apps) and the application server. Portlet container sits on top of the servlet container and provides the interface to portlets. Portal administrator/developers can group any number of portlets into communities, spaces, custom app to create portal apps.
When there is a need to create custom functionality in the portals this is done by writing portlets. Portlets can be deployed locally (running in the portal container) or remotely (via WSRP protocol). Remote portlets are deployed on a Portlet producer (Portlet container) and are rendered on a Portlet consumer app.
Again depending on the vendor there are variations to this architecture. For example Oracle WebCenter Portal version 11G does not support local portlets, only remote. However WebCenter allows using ADF task flows in its “portal” web applications. Some more detail on ADF task flows vs portlets in Oracle Web Center can be found here.
Many existing web application development frameworks can be used to write portlets. Some of them work better than others and may or may not require a portlet “bridge”. Some vendors provide IDE wizards to make it easier to create different technology portlets e.g. Plain JSP portlet, Struts portlet, JSF portlet, ADF portlet, Spring portlet etc… When deciding on portlet technology, consult the portal vendor on their recommendation as some of the portlets technology will have some constraints on certain portals e.g. JSF 1.0 portlets on BEA WebLogic Portal or Rich Faces Portlets on earlier versions of Liferay Portal. Alternatively perform some comprehensive POT (proof of technology) spikes to ensure that chosen portal and portlet technology play nice.
So there is a lot to think about and decide, safe option follow vendor recommendation for tried and tested technology combination.
Portals can be powerful tools that can provide high return on investment for many companies but there are few gotchas to look out for. They can also be lots of fun for the techies. So if you decide to implement a portal, enjoy the ride and remember (as Lance Armstrong says) “It’s not about the bike”!
