Kai Wähner (Twitter: @KaiWaehner, Blog: www.kai-waehner.de/blog) is an IT-Consultant in the Java EE, SOA, Cloud Computing and Big Data world. In his real life, he lives in Erlangen, Germany and works for TIBCO (www.tibco.com). Besides solving huge integration problems for large companies, Kai writes articles for magazines and speaks at international IT conferences such as JavaOne. Feel free to contact him via Twitter, LinkedIn or Email. Kai is a DZone MVB and is not an employee of DZone and has posted 50 posts at DZone. You can read more from them at their website. View Full User Profile

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

10.13.2011
| 36847 views |
  • submit to reddit

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: http://en.wikipedia.org/wiki/Portlet.

 

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 the "BUT" notes after each bullet point).

  • Single Sign On (SSO)

BUT:

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)

BUT:

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

BUT:

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

BUT:

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

BUT:

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?

Conclusion:

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: http://blogs.oracle.com/jheadstart/entry/integrating_a_jsf_application

 

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 :-)

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)

 

[Content from my Blog: Kai Wähner's Blog: Pros and Cons - When to use a Portal and Portlets instead of just Java Web-Frameworks]

Published at DZone with permission of Kai Wähner, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Erron Austin replied on Thu, 2011/10/13 - 1:15pm

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)
Do have more info on the plugins available for GWT? We've had to do a lot of custom work to GWT to work in Liferay.

André Pankraz replied on Fri, 2011/10/14 - 2:48am

Hi,

 

When you speak about additional cost you concentrate on product cost. Really if we calculate and see the word portlet, we just multiply the sum by two ;) just kidding, but you will have higher installation costs, development efforts, QS, more hardware etc.

If you really _need_ a portal 100k for the product are not this much. It also doesn't make sense to speak of Oracle Portal...they have like >4 different portal products. And one of them, the WebCenter family consists of multiple products too. If you buy the full product stack and use some CPU Cores you are fast in this mentioned 200 k range - if you use WebLogic Portal and not much cores Liferay Enterprise isn't this much less.

(And what means propriatary with Oracle? Only because there is "Oracle" as prefix? They really support all kind of standards there, JSR 168/286/ JCR / WSRP 1/2 / JSF Bridges etc.. etc.  Many Portlets that come with Liferay arn't JSR-168-based, they are native...and the CMS access isn't JCR but woven into the system - both are not bad decissions...only like to point out that this proprietary-remark is somewhat strange)

And you also should consider that you need much more CPU/ IO ressources to do the same stuff with a portal than without it. A portal does much more things (huge personalization feature set) on each page and this costs ressources even if you don't use this features. Rendering a portal side _is_ expensive - portlet-based systems are heavy weight by definition. Use a portal as open internet platform and you will get serious problems without the propertechnical background and product experiences.

 

but  when you need a portlet-based portal-product? the point is personalization, custimization, user login, system integration etc.

if you don't need this dashboard features (like iGoogle, but other technology) and don't need login, user self service etc., don't need to integrate lot of different systems, don't have a platform that will be extended in feature, need no CMS features - that are the points where you decide if your architecture is better off with a portal product.

 

Best regards,

André

Kai Wähner replied on Fri, 2011/10/14 - 4:08am

Thanks for your comments.

@André: Well, you are right: You should not consider only product costs (they are not much cheaper for Liferay than for Oracle), but the whole development cycle. Maybe my article was a little bit unclear about this!

I see, you have a lot more experience with Portlets than me. We did not go any further, because we decided that a Portal / Portlets are not reasonable for our project.

Regarding the Oracle stack: We only evaluated the Portal which Oracle offered us combined with its Oracle SOA Suite (WebCenter). I did not make the choice, I just had to evaluate it...

@Erron: As already mentioned, I do not have much experience with Portlets. We decided that it is too much extra effort without creating a prototype or so :-) Thus, I cannot tell you anything about the GWT Portlet plugin. Maybe someone else can?

Ibrahim Levent replied on Fri, 2011/10/14 - 5:06pm

I think the question we should ask is what is the problem we're trying to solve? Web Frameworks and Portals are different solutions for different problems. Portals are full-featured solutions to collaborate, publish and aggregate content on the web. If you want to build a portal site and select web framework way, you need to develop content management, forums and user management etc. Portlets should be coded in both selection but Portals make it easy to program-publish portlets.

"If you decide to use a Portal, you have to choose a Portal product."
You have one more option, you may try to build a custom Portal system(if enough resources available) which is a selection in the middle.
We've recently made such a development and released it. In this way, you don't need to learn a new platform from scratch, everything can comply with your current development environment. In this way, you can use advantages of portlets and portals too.

Javier Saralegu... replied on Thu, 2014/07/17 - 2:28am in response to: Ibrahim Levent

Hi Ibrahim

My company is analyzing your approach, to build a custom Portal system for using the advantages of portlets when a portal system is not used, but we would like to have an initial idea of the development efforts that this solution implies. It would be possible for you to give us some information about your efforts and your experiences with this solution?.

Best regards


 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.