Paul Hinz is the chief marketing officer for Liferay, Inc., the world’s leading open source enterprise portal. Before Liferay, Mr. Hinz led strategies for Java EE and the GlassFish Portfolio product lines and was Sun Microsystems' strategist for portals and collaboration. He has held multiple positions for Sun-Netscape, OSI, Hewlett-Packard and for the California Department of Transportation Research Laboratory. Paul has posted 1 posts at DZone. View Full User Profile

Why Portals are not dead

10.21.2011
| 15054 views |
  • submit to reddit
Portals are not dead, but they were supposed to be. What happened? In early 2000, architects and technologists believed portals were to become the single UI interface for all web applications built by an enterprise. But five years later, most developers had switched from their focus on portals and realized that there were quicker means to develop web UI tasks. However, also by 2005, enterprises were evolving development from standard web applications to collaborative applications with rich UI interfaces.

It was at this time that new portal server technologies entered the market, and at least one of them was called the fastest growing product ever for a multibillion-dollar company. Each new technology was a portal, but somewhat different, which caused product teams to struggle with whether to call the products a portal or something else (e.g., Oracle WebCenter, Sun WebSpace Server). What happened to bring on the resurgence of portals? It may be that the portal as a defined technology followed the standard hype cycle but with a rather longer (or deeper) "trough of disillusionment" than normal. But more likely, portal technology evolved, and additionally, web technology itself evolved.

In 2000, Java technology was increasingly focusing on the Java Platform, Enterprise Edition (a.k.a., J2EE, Java EE) with a defined stack of technologies. Several vendors created application stacks, including an application server, identity management, and messaging layers, with a portal on top.

The portal allowed users to define a website consisting of web pages built with a background theme, navigation and portlets. Portlets could be iFrames, web applications or web content. One of the greatest benefits of the portal was that when tied to the identity management layer, developers could build portlets, add them to web pages and control their access using their existing identity management policy, called role-based content delivery (RBCD). The intent was to simplify the development of web applications across an enterprise, but the complexity of installing, integrating, and developing with the stack caused projects to become too complex. Besides stack complexity, another reason portals lost favor was because they did not include a method to create and maintain web content. Instead portals would be integrated with an existing Web Content Management System (WCMS) or Enterprise Content Management System (ECMS).

Whether or not it came from the same company, it still required you to integrate the two, and coordinate teams using both to create new content. For example, if you wanted a new web page in the portal, you would have to first create the content in the WCMS and then create a portlet to consume that content in the portal. Given that as much as 70 percent or more of every portal page included web content, two steps to create new content was one too many. Lastly, the development of portlets was limiting and complex.

JSR 168 was intended to be a simplified method for building modular applications (portlets) which could be assembled onto a single web page. However, it lacked many features (like interportlet communication). JSR 286 helped, but it still required more work to develop a portlet than just to build a web application from scratch. By 2005, new web 2.0 advancements became popular providing developers richer scripting, simplified integration, and new collaboration services. Developers began to use these other tools to build UIs instead and they relegated portals to corporate-wide applications. But while developers were moving to simpler development methods, they were missing out on the benefits originally designed in the application stack and portal.

The LAMP stack was not supported, so migrations and upgrades were difficult. The LAMP stack also didn’t include WCM. Additionally, a centralized identity policy could not be leveraged across all applications. Last, while new collaboration techniques were becoming available, they were not available as a service in one package, e.g., if you wanted ratings, blogs, wikis, or presence in your application you had to develop them each from scratch or integrate multiple external services. Also in 2005, new portals that provided these features and solved the problems with the old portals began to emerge and grow in popularity.

These new portals were lighter weight (some as small as a 200MB) and were easy to install, administrate and develop against. They often were an entire “application stack” bundle and installed in one step. Velocity and Freemarker were used to increase developer speed, allowing projects to be separated between web developers and business logic developers. These platforms also included a full WCMS, yet could still integrate with an ECMS. They included out-of-the-box collaboration services like wikis, blogs, address books, user-defined communities, and friend networks. And most importantly, they included the original benefits of a portal, a central platform to build web sites/pages using modular components (portlets, gadgets, web content) whose access is controlled by a centralized identity management policy.

Portals have returned to favor as a standard method to build web interfaces, web sites, and web applications. Today they are lightweight, include WCMS and allow developers to deliver social collaboration services faster than with old generation portals or even with standalone web methods pieced together.

Paul Hinz is the chief marketing officer for Liferay, Inc., the world’s leading open source enterprise portal. Before Liferay, Mr. Hinz led strategies for Java EE and the GlassFish Portfolio product lines and was Sun Microsystems' strategist for portals and collaboration. He has held multiple positions for Sun-Netscape, OSI, Hewlett-Packard and for the California Department of Transportation Research Laboratory.

Published at DZone with permission of its author, Paul Hinz.

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

Comments

André Pankraz replied on Sat, 2011/10/22 - 6:32am

Good read.

May be you could add some product examples for light weight portals?

You have a good point with this Portal-CMS-integration. I don't understand the vendors. It never feels right to integrate CMS XY into a Portal, you lose many things and you need it always. Especially bad is the wish for something like JCR (JSR 170) - but hey we can change the CMS later! What a false promise....the customers require it in tenders and the vendors deliver it, it's IT "best practice" after all - not.

I really cannot see the advantage of something like Velocity/Framemaker over JSF Portlets for complex formulars. Maybe template languages are simpler, but only for the simple stuff...where I often don't need a Portal or authentication anyway.

 

Paul Hinz replied on Wed, 2011/11/02 - 5:34pm

There are several lighter weight portals available with built in web content mgmt, social collaboration and integration services. Lightweight is a euphemism, meaning they are not the things that developers and administrators do not like. They have a smaller download size, faster installation, easier administration, and incorporate less arduous development methods. The Gartner 2011 MQ has many light weight portals listed, and a only couple very heavy portals. Most of the heavy portals that did not become leading vendors are gone from this MQ. As to CMS - that is one of the reasons Sharepoint, Liferay, Exo, etc., have had success. They each often have 80% of the features of a full CMS, but those 80% of features are all that is needed 90% of the time, thus the popularity to use the included WCMS. Each of them additionally allow the integration with an external CMS via proprietary connector, JSR-170, or CMIS. A good idea is to use or understand the use of both internal and external content repositories. As to Velocity/Freemarker - you are right. It was just an example of several features added to simplify development in a Java Portal framework, edging them closer to development in LAMP, etc. While I mentioned the goal of many light weight stacks is to simplify development, I should have also mentioned the desire to enable the power user. Microsoft is good at that. I have heard people say, "can you just make it 'Microsoft-like', where if I click around enough I will eventually figure it out?". Several vendors are adding features for the end user, and the power user (see Drupal Gardens, Salesforce portal, DotNetNuke, etc.) who are all adding capabilities for non-programmers. Social Collaboration will probably be the main category where vendors add these features for users. Personally, I believe that basing these power features on a Java stack that simplifies app development and allows scripting and template languages will have the widest adoption.

Jelmer Kuperus replied on Sun, 2011/11/06 - 4:29am

Bleh i really don't like that dzone is providing a platform for marketing types [http://www.liferay.com/about-us/leadership/phinz]. At the very least the fact that the author is a cmo should have been disclosed in the bio. Basically it's the authors job to paint portals in the most positive of light so his opinions are suspect per definition

Robert Craft replied on Thu, 2012/01/26 - 5:55am

Portals are not dead, but they were supposed to be. What happened? In early 2000, architects and technologists believed portals were to become the single UI interface for all web applications built by an enterprise. But five years later, most developers had switched from their focus on portals and realized that there were quicker means to develop web UI tasks. However, also by 2005, enterprises were evolving development from standard web applications to collaborative applications with rich UI interfaces.

Spring Security

Boris Kraft replied on Fri, 2012/10/26 - 3:40am

Portal software’s primary purpose is to integrate apps. Typically this is a one-time task. Once the background business applications are converted into a format the portal can understand and assembled into a page, they tend to stay that way.

Content management, however, is a continuous task. New content needs to be written and published on a daily basis. Writing and publishing content is the most important job in the life cycle of a site. It creates substance and drives users to the site. Over time, content management becomes the most intensive activity on any website. Portal is no exception to this rule.

A portal should be built with software that best supports that key activity – i.e. a Content Management System that makes building portals easy. Read up on the topic in the free (no registration necessary) Magnolia Portals tech-brief from Magnolia CMS, available here: http://www.magnolia-cms.com/resource-directory~categories=Resource-Type_Tech-brief~.html

Comment viewing options

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