Pushing Portal Potential
Portals aren't a panacea. As technology advances, portal development must yield to the complexities of design
by David Hritz

December 17, 2004

Portal applications, which are growing ever more prevalent on the Internet, continue to rank high in popularity. They remain attractive primarily because of the functionality that they provide, but their appeal is also, in part, because they are still relatively the new kid on the block. However, popularity is not usually a good reason for choosing a technology. Portals, like any other piece of technology, have their place, and just because you plan on creating a Web application, you don't need to create a portal. This concept, unfortunately, escapes some people.

To understand the difference, let's start by deciding what a portal is exactly. Originally, a portal was a Web application that could bring together all the applications a user needed into one central location. Whether these modules were new or legacy, they each were componentized and made accessible. Now, mostly everyone is aware that a portal is made up of subcomponents, which are commonly referred to as portlets. Today you rarely see available legacy applications within portals.

Application life spans have shortened, and more often than not as new software enters a corporation, a new services team must be put in place to manage application upgrades. However, this scenario doesn't mean that portals have lost the characteristic of leveraging legacy applications. Now more than ever, portals provide the ability to integrate with legacy applications. What you see in today's business is the creation of new applications, from basic to complex, which are pieced together to form custom Web applications that tie together the entire enterprise. However, one thing has remained static: using portlets to bring together many applications into one place.

As portals gained popularity, portal vendors emerged and began creating portal frameworks, adding to our expectations of a portal. Today's portal software includes a wealth of features that simplify many processes that were once part of the developer's requirements (see Figure 1). It would be impossible to list all of the features available among the different portals that are available today. For this discussion, I have chosen a few features that I use most frequently. Not all of these features will be necessarily included in your portal solution. Check your vendor's feature list for a definitive list of items available to you.

Make It Your Own
Customization is one of the biggest selling points of portal software and portal use in general. Constructs provided in portals allow user access to be configured easily. Not every user has the same rights. A user may have rights to only a handful of portlets, while another user may have access to most of them. Many portal frameworks supply functionality by allowing an administrator to define what each user may access. The presentation of accessible portlets, and more importantly, the suppression of portlets that are not accessible, is handled programmatically by the framework.

Users themselves are often given the ability to modify their own browsing experience by choosing certain features and making component placement changes. These abilities give the user a feeling of power and control over the Web application, which usually results in a more enjoyable experience and thus a more successful application.

Web applications have become very rich with content. It is nearly impossible to have a Web application without content. Any image or block of text can be considered a piece of content. Because of the apparent need, some portals ship with connectors to common content management systems, and some even include basic-to-intermediate content management systems combined with the portal software itself. Content management allows for the separation of content from the presentation layer. Not only is Web content easier to manage in this manner, but it also allows for additional features like user- and role-based content specialization.

Resources that need to be shared among members are found commonly in intranet and corporate portals. Portal vendors have begun providing collaborative tools to facilitate this process. Calendar and events are generally the first to come to mind when thinking about collaboration, and now really any piece of information can be shared among users and groups. Some portals even include features like Web conferencing and instant messaging.

With the growing number of features available in today's portals combined with the masses of users these applications support, user management could be a nightmare. Luckily, software makers have taken the necessary steps to remove the tedium from this chore. Many portals provide a facility to manage the ever-changing needs of its users. I am sure that many of us remember when developers were tasked with developing the needed administration screens for managing an application's users. This task is now a thing of the past with many portal solutions. Included tools provide the means for configuring users and associating them with the many features available.

These features are merely a drop in the bucket when compared to the overwhelming number of features available cumulatively among the many different portal vendors. It would take many articles to discuss all the portal features available from all the portal vendors. The choice of which portal solution is right for the project you are about to undergo is multifaceted. There are many commercially available products as well as a few open source solutions.

The available features of a portal of course play into the decision-making process but not more so than product familiarity. Many commercially available portal products all share a common subset of features. More often a decision is made based on a development team's expertise. Price is another factor, but only in the sense of purchasing commercial software or going with an open source product. In the cumulative cost of developing a project, software purchases make up a minor percentage.

Portal Standards
What first sparked my interest in Java was the power of developing software in a platform-independent manner. With the growing number of portal vendors, there is also a need for portal-independent software. This independence will lead to the creation of vast portlet catalogs, allowing portal administrators to add functionality easily to their portals without having to develop it. If you want to edit text documents on your computer, you don't start within your favorite Java IDE. I am not trying to downplay the wonders of today's portal technology. Many portlets are already available for your favorite portal. However, having a portlet that runs anywhere is much more beneficial to the industry.

The Java community is answering this need. JSR 168 defines a standard for portlet development. Portlets developed under these specifications will run in any compliant portal container, which increases the value of portals greatly by making more portlets available to more people.

Portals are far from your only option when developing Web applications. Just like any other piece of technology, portals satisfy a certain need. If the need is not present, neither should the portal be present. I have seen portal applications developed using none of the functionality gained in the purchase of the additional software, and this tactic is clearly not a wise decision.

Building applications with JSPs and servlets is still a viable option in many cases. Portals may appear to run in fancy containers, but underneath you will find the same JSPs and servlets that we are all used to. Enterprise applications were developed this way before portals, and they will continue to be developed this way in the future. It's unfortunate that some architects and salespeople are too quick to make decisions that affect the entire software development life cycle with only buzzwords and their pocketbooks in mind.

JavaServer Faces (JSF) technology is also new technology that is aiding the construction of Web applications. JSF has proven to ease the development of the application's user interface while also maintaining a clear separation of the presentation logic from that of the application. Some of the features found in JSF resemble features found in portal software. Creating reusable components forms the basis of JSF technology, and these components can then be integrated into a JSP by using custom tag libraries.

As time goes on, we will continue to see the popularity of portals increase, especially with the creation of portal standards and open source availability. Portal software vendors will continue to increase the functionality and productivity of their portals while all the time adding to the feature list. In the future, we will really be amazed by the power of these Web applications.

However, portals are not the answer to all of your Web application needs. Portals provide a lot of features out of the box, but these features are valuable only if they are needed and used. Portals should not be used as an architect's answer to everything. As technology grows and we find at our hands new and intriguing areas of development, as architects we'll need to increase the amount of effort spent toward proper design decisions. Technology advancements usually ease the development process, but normally add to the complexities of design.

About the Author
David Hritz is strategic technology director of smart, innovative solutions and a coauthor of Creating Web Portals with BEA WebLogic (APress, 2003). Contact David at .