Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks

I had to answer the following question: Shall we use a Portal and if yes, should it be Liferay Portal or Oracle Portal? Or shall we use just one or more Java web frameworks? This article shows my result. The short answer: A Portal makes sense only in a few use cases, in the majority of cases you should not use one. In my case, we will not use one.

I had to answer the following question: Shall we use a Portal and if yes, should it be Liferay Portal or Oracle Portal? Or shall we use just one or more Java web frameworks? This article shows my result. I had to look especially at Liferay and Oracle products, nevertheless the result can be used for other products, too. The short answer: A Portal makes sense only in a few use cases, in the majority of cases you should not use one. In my case, we will not use one.

What is a Portal?

It is important to know that we are talking about an Enterprise Portal. Wikipedia has a good definition:

An enterprise portal […] is a framework for integrating information, people and processes across organizational boundaries. It provides a secure unified access point, often in the form of a web-based user interface, and is designed to aggregate and personalize information through application-specific portlets.

Several Portal server are available in the Java / JVM environment. Liferay Portal and GateIn Portal (former JBoss Portal) are examples for open source products while Oracle Portal or IBM WebSphere Portal are proprietary products.

You develop Portlets („simple“ web applications) and deploy them in your portal. If you need to know more about a Portal or the Portlet JSR standards, ask Wikipedia:

Should we use a Portal or not?

I found several pros and cons for using a Portal instead of just web applications.


Disadvantages of using a Portal:

  • Higher complexity
    • Additional configuration (e.g. portlet.xml, Portal server)
    • Communication  between Portlets using Events is not trivial (it is also not trivial if two applications communicate without portlets, of course)
    • Several restrictions when developing a web application within a Portlet
  • Additional testing efforts (test your web applications and test it within a Portal and all its Portal features)
  • Additional costs
    • Open source usually offers enterprise editions which include support (e.g. Liferay)
    • Proprietary products have very high initial costs. Besides, you need support, too (e.g. Oracle)
  • You still have to customize the portal and integrate applications. A portal product does not give you corporate identity or systems integration for free. Software licensing often is only ten percent of the total price.
  • Developers need additional skills besides using a web framework
  • Several restrictions must be considered choosing a web-framework and implement the web application
    • Rethinking about web application design is necessary
    • Portlets use other concepts such as events or an action and render phase instead of only one phase
    • Frameworks (also called bridges) help to solve this problem (but these are standardized for JSF only, a few other plugins are available, e.g. for GWT or Grails)
    • Actually, IMO you have to use JSF if you want to realize Portlets in a stable, relatively „easy“ and future-proof way. There is no standard bridge for other frameworks. There are no books, best practices, articles or conference sessions about Portlets without JSF, right?


Advantages of using a Portal

Important: Many of the pros can be realized by oneself with relatively low efforts (see red font).

  • Single Sign On (SSO)

Several Java frameworks are available, e.g OpenSSO (powerful, but complicated) or JOSSO (not so powerful, but easy to use).

Good products are available, e.g. Atlassian Crowd (I love Atlassian products such as Crowd, Jira or Confluence, because they are very intuitive and easy to use).

  • Integration of several applications within one GUI
    • A portal gives you layout and sequence of the applications for free (including stuff such as drag & drop, minimizing windows, and so on)
  • Communication between Portlets (i.e. between different applications)

This is required without a portal, too.

Several solutions can be used, such as a database, messaging, web services, events, and so on.

Even „push“ is possible for some time now (using specific web framework features or HTML 5 websockets).

  • Uniform appearence

CSS can solve this problem (the keyword „corporate identity“ exists in almost every company).

Create a HTML template and include your applications within this template. Done.

  • Personalization
    • Regarding content, structure or graphical presentation
    • Based on individual preferences or metadata

Some of these features can be realized very easily by oneself (e.g. a simple role concept).

Nevertheless, GUI features such as drag & drop are more effort (although component libraries can help you a lot).

  • Many addons are included
    • Search
    • Content management
    • Document management
    • Web 2.0 tools (e.g. blogs or wikis)
    • Collaboration suites (e.g. team pages)
    • Analytics and reporting
    • Development platforms


A) Do you really need these Features?

B) Is the offered functionality sufficent? Portals only offer „basic“ versions of stand-alone products. For instance, the content management system or search engine of a Portal is less powerful than other „real“ products offering this functionality.


Thus, you have to think about the following central question: Do we really need all those features offered by a portal?


The total cost of ownership (TCO) is much higher when using a portal. You have to be sure, that you really need the offered features.


In some situations, you can defer your decision. Create your web applications as before. You can still integrate them in a Portal later, if you really need one. For instance, the following Oracle blog describes how you can use iFrames to do this:


If you decide to use a Portal, you have to choose a Portal product.

Should we use an Open Source or Proprietary Portal Product?

Both, open source and proprietary Portal products have pros and cons. I especially looked at Oracle Portal and Liferay Portal, but probably most aspects can be considered when evaluating other products, too.

Advantages  of Oracle Portal

  • Oracle offers a full-stack suite for development (including JSF and Portlets): Oracle Application Development Framework (ADF)
  • Oracle JDeveloper offers good support for ADF.
  • Everything from one product line increases efficiency (database, application server, ESB, IDE, Portal, …) – at least in theory J

Disadvantages of Oracle Portal:

Advantages  of Liferay Portal:

  • Open source
  • Drastically lower initial costs
  • Lightwight product (1-Click-Install, etc.)

Disadvantages of Liferay Portal:

  • Not everything is from one product line (this cannot be considered as disadvantage always, but in our case the customer preferred very few different vendors (keyword “IT consolidation”)
  • Portlets are still Portlets. Although Liferay is lightweight, realizing Portlets still sucks as it does with a proprietary product


When to use a Portal?

Well, the conclusion is difficult. In my opinion, it does make sense only in a few use cases. If you really need many or all of those Portal features, and they are also sufficient, then use a Portal product. Though, usually it is much easier to create a simple web application which integrates your applications. Use a SSO framework, create a template, and you are done. Your developers will appreciate not to work with Portlets and its increased complexity and restrictions.


Did I miss any pros or cons? Do you have another opinion (probably, many people do???), then please write a comment and let’s discuss…



Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Dont‘ miss my next post. Subscribe!

We don’t spam! Read our privacy policy for more info.
If you have issues with the registration, please try a private browser tab / incognito mode. If it doesn't help, write me:

  1. Hi,

    I have long experience with building websites and horizontal portals for my company customers. First we stared with our own CMS based on our own framework but since 2009 we are using Liferay for most of our webprojects.  

    I think you missed couple of things in your article. First, building a template of features stack that you need in your projects is still a big cost. You can use JOSSO, some kind of simple system for managing text on your website, maybe gallery (there are many open source web gallery system) but at the end it will give you a product with many technologies, written with using many frameworks and integration quirks. You will have source code that is not always written the same way and with the same quality.

    Portals lower your upkeep cost and often lower your initial cost as most of things are there out of the box. Preparing authorization with few clicks is always faster than writing a template for yourself.

    I will agree that you must always ask a question – do I need those things at all 🙂

  2. I agree and perhaps more strongly. I don’t see a reason to built a web application that targets a portal. The portal could be useful for a business but should be consider as a separate product (like a CMS). The portal might provide SSO which the web app can integrate with. Also the portal can pull content snippets into it’s pages but having the web app serve those snippets directly (or perhaps just JSON data to be styled by a portlet – or some similar portal component/plugin). In this way it doesn’t matter what technology you use for your web apps – PHP, Python/Django, Ruby/Rails, Groovy/Grails, Scala/Lift, Scala/Play, Java/SpringMVC, C#/ASP.NET etc. Specifically, it seems nuts to buy a portal if it were to force all web app development to happen in Java. Perhaps I’m missing something?

    I could be tainted as my only experience building Portlets was before web app frameworks had decent support for them (late 2004). Specifically one of our devs spent days debugging and patching DisplayTag for table display/sorting.

  3. Just rename the article to, “Do not use Java Portlets, let me tell you why.”
    Writing all of the pros in red font, as if they are lies, is a nice touch.
    Lets face it, everything is easy to write on your own, until you actually start doing it.

  4. A nice article indeed. However, I wouldn’t dismiss the integration of different applications so easily. Without a portal you’re probably going to write a (simple) umbrella application. In other words: you’re wrting your own lightweight portal server :).

    Apart from that, portals are a chore to the developers. The one thing you didn’t mention – the turn-around cycle – is going to drive you nuts. Wait do I have to wait 30 seconds each time I correct a simple typo?

    By the way, JSF 2.2 will be incompatible to portlets. And afaik it will be very difficult to fix this one :(.

    Best regards

  5. It’s really interesting how a post from 2011 still gets responses in 2013 (like this). To me sounds like Portals are still alive and serving request in many places, mostly enterprise, tough.
    I agree with TTucker about the name of the article, it should be changed to “Reasons to not use Portals”. It doesn’t provide any useful insights to the subject.
    I was looking for experiences and stories using both, Portals and Web Frameworks, and detailed pros and cons for both. I’ll keep looking.

  6. The pro’s of a Portals are promises the management likes to hear (faster development, easier integration, etc…).
    The con’s of a Portal is the reality which the developer experiences: an overloaded patchwork broken by design!
    I had to work with Liferay, and i didn’t like it.

  7. When using portals, I found the performance overload tremendous. It seems to me as if portal solutions might be a bit out-of-date in times of plenty of JavaScript GUI libraries transferring most part of application logic into the (nowadays fast) browser whereas a lightweight server part for the really needed data and as connection to the backends is sufficient. This way, portlet technology might be a bit old fashioned.

    Nevertheless, points in favour of a portal solution might be intrinsic support of social networking, collaboration means (CMS/document system, workflows) or sophisticated access right granulation. Nevertheless, even then, we have the performance issue and the initial setup effort. In each case the complexity requirements and the project size must be rather high to justify portal usage.

  8. Nice article Kai. I have worked on various Liferay and JEE projects for around 10 years. Trust me, almost none of the LR projects really uses liferay’s OOTB portlets or features. They could have been easily made using some other JEE framework like Spring.
    Recently we tried to move from LR 6.2 to LR DXP and it seems impossible to move all our portlets(15) to OSGi. Instead we started to move our portlets to Spring Boot applications.
    May be you can write an article about LR DXP and migration 🙂

Leave a Reply
You May Also Like
Apache Kafka and PLC4X Architecture for IIoT Automation Industry
Read More

Apache Kafka, KSQL and Apache PLC4X for IIoT Data Integration and Processing

Data integration and processing in Industrial IoT (IIoT, aka Industry 4.0 or Automation Industry). Apache Kafka, its ecosystem (Kafka Connect, KSQL) and Apache PLC4X are a great open source choice to implement this integration end to end in a scalable, reliable and flexible way.
Read More