; last updated - 11 minutes read

This year's JAX conference left me with the impression portal servers are a fashion in decline. How can this be? Just a few years ago virtually everybody was talking about portal servers, claiming them to be the future.

Portal of the Vieja Catedral in Salamanca. Does your customer need such a portal? Does it need a Java portal server? (C) 1997 Stephan P. RauhNow it seems "virtually everybody" were the marketing guys. The majority of the Java world gracefully ignored the self-acclaimed fashion and went on developing other frameworks like Spring, JEE, HTML5, just to name a few.

All right, that was then. What about today? Do you need a portal server? Or rather: Who needs a portal server?

Why are portal servers that attractive?

In some countries the word "portal" has a nice ring to it. Germans in particular use the word "portal" almost exclusively to talk about the impressive if inviting doorways of old churches. Everybody who reads about a portal server can't help but think about something like the picture above. So it's not surprising he'll say "Yes, I do want a portal server". That's a great misconception. He doesn't want a portal server, he wants to have an attractive web site. You can build such things both with or without portal servers.

Let's have a look at Java portal servers. A portal server is a web application server delivering a lot of infrastructure and a lot of useful programs. You get an elaborated user management with single sign on, you get a menu, you can add your programs as well as third party programs. You get a content management system, a forum, a blog, chat, calendars. The list of pre-defined applications is sheer endless. Portal servers allow you to work collaboratively. Portal servers give you a powerful search engine. It can find everything in the portal, even your application's data. Just have a look at Liferay's[1] home page to get an impression of the wealth of features.

The reality check

While everything I mentioned above it true, it's time for the reality check.

A particular annoying promise is Single Sign On. Most portal providers define single sign on as a technology that forces you to log in only when you open the portal in the browser. To people like me who tend to close the browser every five minute, this so-called Single Sign On results in signing on every five minutes. Calling this "Single Sign On" is bending the truth, if not worse. Sometimes you can use Window's authentication to alleviate the pain, but that's not portal technology. It's Windows, and it can be done without portals as well.

When I had a close look at Liferay's forum, its document management and its content management system, I was disappointed. Obviously it's not easy to support every need in the world at once. Yes, you can use the content management system, and it has improved over the years, but it's still a far cry from Confluence's ease of use. The same applies to a lot of pre-packaged portlet Liferay delivers. It just like comparing Windows' Paint program to Photoshop (or comparing Wordpad to Word). You can use it, but there's better software. A software forge dedicated to a certain product can easily outrun a manufacturer trying to support everything.

A developer's view

As I mentioned, renowned portal servers contain everything and the kitchen sink. They can do virtually everything. But this power doesn't come for free. Mind you, if you're buying a car that has a lot of power and can serve every of your needs, you'll end up with a truck. It's got 500 HP and 28 tons of payload, but it's no fun to use it to buy a loaf of bread (especially, if you're living in an historic european town with narrow streets).

In other words: portal servers are a lot slower than simple application servers like Tomcat or Jetty. Applications run a lot slower. I measured roughly an extra second on every page refresh. And there's more. A simple application server like Jetty starts in less than a second[2], while Liferay take at least 30 to 90 seconds to start. The turn-around cycle is hardly noticeable if you're using Tomcat. You can editing and test a web application without delays (what a wonderful thing Hot Code Replacement is!). Doing the same in a Liferay portlet requires a full redeployment and takes at least 30 seconds. Every time, even if you've corrected just a typo. And as far as I know, Liferay is one of the better portal servers.

In other words: portal servers make for a bad developer experience. Turn-around cycles are slow, and developer productivity is low.

Using advanced features of JEE

Portal technology has been developed independently to JEE. For some reason, this led to serious incompatibilities. One outstanding reason are the different life cycles of portlets and servlets. If you want to use standard technologies like JSF or CDI, you have to write or use a bridge. Even simple features like file download don't work. As it happens, there is a JSF bridge, and a CDI bridge is under development, but those bridges have their limitations. The JSF bridge doesn't repair the standard JSF file download feature. The bridge - now called LiferayFaces - delivers its own file download feature, which is useful if you know it's there. But you can't expect to simply convert a standard JSF application to a portlet without pain. And you can't expect to get the examples you copied from the internet tutorials up and running. Some work, some don't, and you never know in advance.

Sometimes you're even cut off from progress. For instance, JSF 2.2 is going to have new incompatibilities to the portlet specification.

Strange errors

An experienced portal developer once told me: "Sooner or later you need to debug the portal servers source codes". I never needed Tomcat's source code to write my application, so I suspect there's something wrong with the portal approach. I didn't debug my portal server yet, but our programs showed a lot of strange errors that might have been solved by debugging the portal server. A weird idea given the server is meant to help me instead of standing in my way.

Does a portal server help you writing applications?

No. A portal server allows me to write portlets, not application. The difference is portlets are meant to be small fragments of an application.

The portal server provides me with a user and rights management system. That's nice, but on the other hand, it's not that difficult to access a user and rights management like LDAP in Java. The other benefits of a portal server are the menu and the window management. It's takes five minutes to write a JSF menu, and I never needed the windows management so far. So the features a portal server gives developers for free are a mixed blessing.

A very interesting portal feature is the search engine. You can configure the portal server to include your portlet and its data in the search. If you need something like this, portal servers are just great. But then - did your customer ever demand such a thing?

Inter-portlet communication

Portal server advocates never fail to mention inter-portlet communication. Portlets can broadcast messages and subscribe to message in order to exchange messages. The portal evangelists claim this to be a big advantage.

That's rubbish. You need inter-portlet communication because using portlets means to split an application's window to small tiles. Those tiles are isolated applications. They don't know of each other. If they belong to the same application, you need a solution. IPC comes to the rescue.

Using web applications the solution is much more simple. They aren't divided artificially to small fragments, so there's no need to communicate. The only advantage of IPC is it allows different web applications to communicate with each other. But this is a rare use case, and the solution is far from being simple and elegant.

The portlet standard

There are two JSRs defining a portlet standard. The bad thing about these standards is that they define the least common denominator. Generally, it's a good idea to stick to standards. But if your customer wants you to write an application running in a portal server, you'll find yourself using vendor specific features in no time. You should bear this in mind when you chose a portal server. Chances are you can't switch to another portal server later. Your first choice has to be a good one for it might be the final choice.

By the way, integrating portlets into the search engine aren't part of the portlet standard.

Beware: Adopting a portal server may amount to drop existing infrastructure

Chances are you already have a content management system. If so, you should think twice before buying a portal server. As I mentioned above, the build-in content management system's usually not as good as the content management system you already have. But you don't want to have two content management systems, either.

Detail of the doorway of the Vieja Catedral in Salamanca. Look at the wealth of details. How big may the maintenance bill be? (C) 1997 Stephan P. RauhConclusion

Don't take me wrong: portal servers are great software. They can be very useful tools. But they are not useful for every task. In particular, if you customer wants you to write an application, delivering a bunch of portlets usually is a bad idea. You can make it work, but it comes with a heavy price tag.

By the way, in many cases it might be a good compromise to write a traditional application and include it as an iframe. Still, it's a painful compromise (you have to deal with a menu bar outside your application, for example), but this approach is a lot cheaper than writing native portlets.

Unless your portlets really make use of the portal server's features. At the end of the day, it depends on your customer's needs. Sometimes you'll be happy to use a portal server, even as an application developer. But I suspect this doesn't happen very often. Remember the doorway of Salamanca's cathedral: it's a great portal, but do you want to use such a portal as your companies entrance? Just have a look at the small details - they amount to a huge maintenance bill!

Oh - and as you're at it: the little figurine in the center of the photo is real. It's been a a student sculptor's joke back in 1992.


Further reading

http://wiki.ipponsoft.de/graphics/XPUG_2010-02-10_Zukunft_von_Enterprise_Portal_Servern.ppt Die Zukunft von Enterprise Portal Servern (PowerPoint, in German) (Update Sept 17,2014: the link seems to be broken)

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


Comments

Currently, my blog doesn't display comments properly. With so many spam comments, I obviously made my blog to secure... as a workaround, I publish the comments manually:

Great blog post. I absolutely agree about this Portal stuff.

I have written a similar blog post about pros and cons of a portal some months ago:

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

Best regards, Kai Wähner (Twitter: @KaiWaehner)


  1. Of course, Liferay is just an example. Other portal servers offer similar features.↩
  2. At the time of writing, Tomcat takes roughly 4 seconds on my machine. Jetty's an extraordinary fast starter.↩

Comments