Portal Development Basics Part 1

Portal Development Basics Part 1

If you have been part of application development or even if you are application user for a quite long time now, then you must have sensed that heart of any application is “content”.  As things advanced we realized that “user experience” is important as well. The lack of a standard approach and technology to address user-experience requirements, such as personalization, customization, and content aggregation in web applications, led to ad hoc ways of implementing these features. The result was maintenance nightmares, lost developer productivity, and longer turnaround time for incorporating new features.

With evolving Java portlet technology it allows us to quickly develop a web application providing service orchestration. Java portlet technology it isn’t standalone technique to achieve development, it uses traditional JSPs and servlets to build application along with portlet. On top of that there is MVC frameworks like Spring MVC portlets allows you to develop individual portlets in the Spring technology. This blog shall aid you understand fundamental need of portal development and getting familiar with different aspects of it. Next blog will talk more technically about different standards of Java portlet technology JSR 168 (Java Portlet Specification V1.0), JSR 286 (Java Portlet Specification V2.0).

Portal Overview

A portal is a web based application that comprises of many small web applications called “portlets”. Primary goal of a portal system is to facilitate personalization, authentication, and content aggregation from different sources and hosts the presentation layer of information systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users.

To get a feel for portals, you can visit the iGoogle portal (http://www.google.com/ig).  In the iGoogle portal you can see portlets showing emails from Gmail, headlines from CNN, content from YouTube, and so on.

Portlets are not widgets

While looking at iGoogle example you might start wondering what makes portlet different than web widgets as we know today. A developer can quickly develop widgets having some knowledge of Javascript and XML, however Java portlet concepts require deep learning curve to understand its fundamentals. Portlets are well suited for medium to complex application requirements as found in enterprise applications.  

Why use portal?

Quick answer is when you want to develop service oriented architecture. As portlets represent services and are pluggable components, you can get plug and play behavior using portlets. Because portlets can interact with each other at the user interface layer (a process referred to as inter-portlet communication), they play a major role in developing SOA applications. The portlet container is responsible for handling the communication between portlets.

The portal infrastructure, which includes a portlet container and portal server, provides portlet instance lifecycle management, instance pooling, content caching, security, a consistent look and feel, and single sign-on features to your web portal.

Let’s take example of iGoogle portal we talked about. As a user you need to frequently check your emails, browse videos on YouTube, take glimpse of news from news articles and keep updated on technology trends. All of these web applications have their own business requirement and data sources which you will need to browse individually. If we have a single point of entry using a single sign-on feature to allow access to all of these applications then that would be better solution.

Let’s say that as an employee of an organization you need to frequently access organization-specific business-to-employee (B2E) applications (like time card, help desk, knowledge management, and service request applications) so you can keep track of missing time cards, recently published articles, closed help desk tickets, and so on. These different web applications have their own data sources, and you’d usually need to go to each of these different applications to access this information. Certainly this isn’t an optimal way of accessing information and services, because you need to go to different web applications and authenticate each time. An intranet site that provides a single sign-on feature and access to all these different applications would be a better solution.

By providing the single sign-on feature, if the service provider has provided easy access to the B2E applications, but you still need to filter the information that interests. Like if you interested to know more about Java technology trends only. You will have to search for Java articles in primary application. Individual application will have some level of user preference managed as personalization. But ideal scenario for user to have unified view of all services is in single application itself. This is achieved using portal development as seen in iGoogle today.

The portlets can be personalized by users to change the number of emails displayed in the portlet, the number of CNN headlines they want to view, the location they want to receive RSS feeds from, and so on. Users can drag and drop these portlet windows on the portal page to customize the way.

Where portal doesn’t work?

Portals aren’t the answer to every business requirement; organizations should consider carefully whether there is a business case for developing a portal. If the requirement doesn’t require gathering content from distinct information systems to loosely integrate disparate systems, the business should consider developing independent web applications to meet the business requirement. The personalization and customization features of portals are important from the user’s perspective. From the business’s perspective, the most important requirement to consider is content aggregation.

Reference

Portlet In Action