So What Are Enterprise Portals All About?

There are many definitions for “Enterprise Portal”, this article aims at exposing a definition that is commonly shared in the Java EE world. People's understanding of portals usually differs depending on their background. PHP people usually see a portal as a bunch of blocks on a page, ECM people would see a portal as a delivery platform for their content, Dreamers see this as an off-the-shelves components that you can stick together through some kind of mashups and so on... At the end everyone agrees, portals are all about integration.

A portal must offer a single point of entry to multiple applications and they all must be well aggregated on a page so that the user doesn't have a Frankenstein feeling while navigating the portal. Last and probably the most well known part of a portal framework is about personalization. Once logged-in, the portal should be able to deliver content depending on various settings defined by the users.
While this article remains as neutral as possible, the author is leading the JBoss Portal project and JBoss Enterprise Portal product. The next article will cover JBoss Portal, while this one covers portals in general. Hopefully at the end of this article you should be able to decide if a portal should be part of your architecture or not.

Integration

A portal should be able to integrate into an existing infrastructure, it may not be the only component of a company and must be able to play well with the other parts. It means that the portal application can integrate with any SSO solution already in place or any identity solution which could be based on a database or an LDAP directory for example, data might already be existing and should not require to be modified.
It also means that a portal should not mandate your architecture but adapt to the one you want to build or already have.

[img_assist|nid=7437|title=Figure 1: The portal integrates in an existing infrastructure|desc=|link=none|align=undefined|width=470|height=237]

Aggregation

Sooner or later a company has to deal with multiple applications written with different technologies

Various Applications

A portal should let the architect define multiple applications that will be in charge of rendering a fragment of a page. The first benefit is that multiple parts of a large projects can be easily divided into teams, the aggregation work will be done by the portal.

A portal framework should be able to aggregate any type of content, but in order to make the  components (applications) more unified the portlet specification was born. It enables those components to use a common API and make those components runnable within any portlet container implementing the specification such as Red Hat (JBoss Division), IBM, Oracle...

The portlet specification defines a simple low-level API on which web frameworks can rely, this is not a surprise that you can run Struts, JSF, JBoss Seam, Wicket, WebWork, GWT , Spring MVC, (PHP to some extend)... applications as portlets. It is then possible to mix applications written with different technologies on a single page transparently to the user. Soon or later a company has to deal with multiple applications written with different technologies. This could be the result of a company acquisition, dying technologies that need to be replaced or multiple teams that can't agree on a common framework.

Many companies keep using a framework just because they have been using it for years or require users to access a separate portal to use applications coming from a company acquisition.
This aggregation capability also allows for wider choice when shopping for applications. If you are a Struts user and find the forum application having all the features you need but written with JSF, this shouldn't be a showstopper. Another benefit is that multiple teams can work on their preferred framework without necessarily having to come to an agreement.

[img_assist|nid=7438|title=Figure 2: Aggregating multiple applications from various web frameworks|desc=|link=none|align=undefined|width=274|height=335]

Portlet Bridges

To be able to write an application in JSF, Struts, PHP or any other framework, someone needs to provide a piece of code that defines the relation between the portlet specification and the framework, we call this piece of code a 'Portlet bridge'. The portlet Bridge uses the low-level Portlet API to let the developer forget about it (Like most Web frameworks make you forget about the underlying Servlet API).

[img_assist|nid=7439|title=Figure 3: Portlet bridges stack|desc=|link=none|align=undefined|width=431|height=236]

Federation (WSRP)

Web Services for Remote Portlets is a service that allows for federation of portlets from different portals. This is again a fairly interesting aggregation point used mostly by either very large corporation or as a way to migrate from a portal vendor to another.

A WSRP portlet can be produced by a portal (not necessarily a Java Portal) and consumed by another portal. Most Java EE portals embed a WSRP producer and consumer but Microsoft Sharepoint does to for instance. It is then possible to produce a fragment of a page in a Java EE Portal and render it in Sharepoint (or the other way around).

WSRP has not (yet ?) achieved its goal to be used as a way to share and consume applications with external vendors. One use-case would have been to be able to sell content without going down to web-services or REST API level but directly delivering the HTML, a bit like widgets are doing today.
That said WSRP users found their interest in multiple scenarios, the first use-case is seen in companies with tight legal issues (or security issues) where some data for one or more applications must be physically located in some place and other in another place. Say an international company stores its customers data in their own countries and each country IT service publish data the way they want to the other countries.

Another scenario is about migration. We've seen that the portlet specification enables portlet developers to write applications that can run on any portal supporting the specification. Quite often, they will want to use features that are specific to a portal, and then make the portlet tied to the specific portal vendor for which it has been developed. One way to circumvent this is to keep the faulty portlet running in its portal and produce it so that it can be consumed by the newer portal on which more recent portlets have been developed. It can save a lot of money by reducing the number of required licenses for proprietary portals.

[img_assist|nid=7440|title=Figure 4: WSRP consumption from a remote portal|desc=|link=none|align=undefined|width=444|height=213]

Widgets/Portlets

A portal does an aggregation job, JSR-168 (Portlet 1.0) and JSR-286 (Portlet 2.0) are very good citizens of a portal since the specification has been designed to solve issues when having to handle multiple applications in a single request. But portlets don't have to be the only actors in a portal. Widgets have entered the market loudly since they can easily be integrated in any HTML browser with Javascript support enabled. Widget became a natural component for portals, while they don't offer a way to communicate together, can't be part of the single-sign on solution and cannot access user preferences (They usually have their own way to store preferences on the widget server), they can still be interesting because of the number of available widgets.

A lot of portals are able to integrate widgets like they do with portlets, again this is usually transparent to the user if they are using one or the other.

Single Point of Entry

As we have seen, a portal framework aggregates multiple applications in a transparent way, several of those applications (if not all) will likely need a registered user to delivered a customized content.
Flexible portal frameworks will be able to adapt to any authentication method choice, while most portal will use a username and password combination, a bank will probably add a one-time-password token to it or require to have a certificate installed on the user's machine. In any case once that authentication done on the portal, the user will usually never be prompt again for the lifetime of his session even though he will transparently use several web applications during his visit.

Personalization

Personalization of the portal is a major feature of a portal framework. The portlet specification offers an API in order to adapt the content of a page based on the preferences of the user. A portlet developer could also adapt content based on the user profile or information given by the portal such as the preferred locale for the user (which could be computed from the user's browser preferences).
Some part of the portals may also be restricted to some users.

User Preferences

The portlet specification comes with an API to define user preferences, it is up to the portal framework to store those preferences. An RSS feed portlet will probably let the user define how many feeds the user want to see while the administrator will want to be able to adjust the default value for such a preference.
At the portal level, a theme engine could let the user set the theme of his choice also based on the user preferred language display content accordingly.

Sometimes a portal may also allow users to have a personal dashboard which is a place where the user can create his own pages and compose them with components of his choice.

Permissions

From the administrators point of view, they may want to restrict pages or windows to certain users or group of users, most portal framework will come with a way to restrict access wither through an API and/or GUI. It also enables to provide a personalized view depending on the user (Such as showing some customer information to a salesperson, instead of a product catalog for a customer).

Conclusion

To conclude, a portal framework exists to solve personalization, and aggregation issues so that developers don't have to reinvent the wheel. Those issues are common to all portals that want to integrate in an existing infrastructure, which have several applications to aggregate or want to provide a personalized experience to the visitor. Differences between portal frameworks comes to their ability to work in a cluster environment for fail-over and scalability, support for web frameworks but also on how they can adapt to the architect and infrastructure requirements.

Thomas Heute
JBoss Portal Lead