PORTAL CONCEPTS

A portal is a single web interface that provides personalised access to information, applications, business processes and much more. With portal technology, your organisation can lower development and deployment costs and significantly increase productivity. You can aggregate and integrate information within a particular working environment, application or service, or use a single interface to target an individual users' needs and interests. Portals help to harmonise content, commerce and collaboration with business goals. This section describes their potential to enable collaborative work, manage large amounts of disparate content and power high-end e-commerce facilities. In the simplest terms, a portal is a web site that provides content and application functionality in a way that is both useful and meaningful to the end user. It also serves some purpose from the portal provider's perspective, whether it is a public portal trying to attract web traffic to the site or an enterprise desiring to provide a central location for employees to obtain company information. Initially, a portal was simply a mechanism to aggregate a related set of content presented as a set of links to the originating site. Over time, portals have evolved to enable the ability not only to provide a unified look and feel to the entire site, but to apply personalization and customization to the content. In this way, a person who accesses a portal and logs in with a pre-defined username and password can customize not only what portal content is displayed for them, but how that content is displayed. Most portals and portal frameworks contain the concept of a "portlet" as a window to a specific set of content within the overall context of the portal page. Most portlets support the ability to customize the information displayed within this window. From the perspective of the portal framework, portlets tend to look and behave much the same as individual windows running in any windows-based operating system. They can be minimized, maximized and re-arranged to suit the individual portal user. From the developer perspective, a portlet is really a piece of code that plugs into a generalized framework. Different portal frameworks implement the concept of a portlet differently. In some cases, the portlet is a collection of JSP pages. In other cases, it may a special type of class that implements certain interfaces. Regardless of how it is implemented, the portlet is generally responsible for presenting a specific set of content that may be tailored to a user's preferences. The portal framework is responsible for handling the infrastructure services, such as providing the overall presentation, user management, security and personalization. When a user authenticates or logs into a portal, there typically is a set of characteristics of the portal that are tailored specifically to that user or users within a pre-defined group. At the very least, this would include which portlets are available to the user to display. For example, a regular employee logging into an employee portal may see the stock price of the company, company news, and even department news based on the group they belong to. A manager logging into the portal may see all these things as well as an expense authorization portlet that would list expense reports their employees have submitted that are waiting for approval. Associated with personalization is the ability to customize the portlets within the portal for a specific user that has logged on. This may mean choosing which portlets to display, how to organize them on the page and even the specifics of the content within the portlet. One final important concept associated with portals is commonly referred to as "skins". A skin is the idea that the portal can define a standard look and feel for all the portlets and the page the portlets are displayed on. This may include such things as background page color, font color, font type, special logos, etc. In many cases a user can choose a skin from a list offered by the portal provider.

Technical Advantages of Portals The technical advantage of portals is their capability to help organisations harmonise and rationalise IT operations. The result is greater efficiency in development and deployment, as well as security, management and user acceptance. Addressing Complexity Portals are cost-effective from a technical standpoint. They leverage existing technology and simplify development and administration by reducing the number of required systems. However, to reach their full

advantage, portals must not be seen as standalone projects. Rather portals should be considered in terms of a broad enterprise-wide endeavour. Taking an integrated approach to portals means IT departments can reduce the complexity and variance of the technology in use. Where implementation is fragmented, developers may be familiar with one portal technology and not another. Software code and the overall approach taken in one portal technology may not apply to another. Different databases, disparate content management systems and dissimilar web page rendering technologies can all consume time and resources. Instead of improving efficiency, costs will rise. When an organisation approaches the development of a portal correctly, the project will offer major advantages. In such cases the portal will be part of a framework that is scalable and flexible. Security One great advantage of portals is that they enable "single sign-on" capability. In contrast to having many systems, each with its own user ID and password, portals simplify the issues around management and security. Application Integration Linking separate systems together is key to developing an environment that fully supports business processes. Exposing information from a range of systems via portals supports this approach. Systems such as HR and accounting need not be directly integrated within a portal implementation but relevant information can be made available on demand through a portal. Content Aggregation and Search The proliferation of documents and information resources demands that organisations aggregate content and provide advanced tagging and search capabilities. A portal brings together content from disparate sources, displaying results through a single interface. The key factors in developing a superior search function are the quality of the taxonomy and categorisation processes and having the capability to find information held in a variety of file formats via keywords and other methods. Any user security conditions in place will also need to be applied to the search process. Web Content Management This describes the process and practice of managing information created in a web environment, in contrast to content management systems handling information created via alternative means. Web content management encompasses the entire process of authoring, storing and managing resources created purely in that domain. Creating and managing unique content developed for the web is increasingly seen as an essential organisational capability. Analytics and Reporting Online business analysis and reporting functions assist organisations to become more effective. Gigabytes of data can be held within a web environment, recording click through data, user behaviour patterns and more. This data can reveal important trends and developments on a website and introducing online analytics can lead to more intelligent decision making. Many companies fail to use this data adequately. Multilingual Capabilities Portals are capable of delivering content in multiple languages, while maintaining design consistency based on templates. Where content is localised you can ensure that it conforms to centralised content controls and appearance. Rendering Content on Different Devices Portals enable information to be delivered to multiple devices. This includes different forms of PC, as well as the full range of mobile technologies. PDAs, smart phones and other handheld devices are all capable of receiving information. A portal must accommodate this diverse set of browsing devices without requiring extensive reprogramming or maintenance of multiple portal sites.

Features Checklist
Outlined below is a checklist of features you should expect to see when evaluating portal solutions:
What Can You Expect From Your Portal Platform?
Goals Features Secure, Personalized Delivery of Targeted Content

• •

Personal Portal - A web page or site that individual users customise with information, links and data of interest. User profiles - The collected information about a user's identity, preferences, portal layout, selections and choices. This allows a range of personalised features to be used, making it easier for users to connect with other people.

Subscription and alerts - Automated notification for users when important information, events or changes occur.

Integration for Business Applications

• •

Integration with productivity applications - Knowledge workers spend much time using office productivity tools, which can be brought together via a portal. Application integration infrastructure - Integrate across operating systems, databases and development environments.

What Can You Expect From Your Portal Platform?
Goals Features Easy to Use Collaboration Tools

• • • •

Ad hoc collaborative spaces - Team working and community portals support websites for group or task-based activity. Document management - Gain support for document management, information sharing and collaboration. Workflow - Managing collaborative processes involves developing support for a workflow infrastructure. Real-time communications - Important communications now take place in real-time using instant messaging and chat.

What Can You Expect From Your Portal Platform?
Goals Features Broad Search, Indexing, and Categorization of Content: Categories and Taxonomy

• • • •

Multiple content types - The capability to handle different types of content, including email to ensure seamless information flows. Best bets and categories as search results - Deliver search results based on the nearest match and the categories revealed. Auto-categorisation - Tools to automate the cataloguing or categorising of information. Expertise and affinity identification - Connect people to share individual expertise and the knowledge built up by teams.

What Can You Expect From Your Portal Platform?
Goals Features Security Simple Centralized Management Tools

• • • •

Flexible deployment options - Portal architecture can take three forms - top down, bottom up and mixed. Single sign-on - Authenticate users based on a single sign-on process to access content and systems. Directory-based identity management - Identity management via a directory service associates users with roles and functions. Self-management - Delegate portal management to users.

• • •

Access Control List Security - A list of access privileges defines who can access particular resources Rights-Based Security - Access levels are determined based on the roles played by individuals. Managing Security - Portals must be easy to manage and deploy, with centralised security being crucial.

Introduction Web portals have risen in popularity as a way of aggregating, organizing and presenting content in a highly uniform, customizable and personalized way. As the technologies that enable the creation and management of these web portals have evolved, it is not only information content that is being offered, but application functionality as well. With application functionality making its way to the web portal, a whole new dilemma is encountered as developers attempt to adapt their application functionality to the characteristics and behavior of the web portal. Portal concepts Portal is a web site that provides content and application functionality in a way that is both useful and meaningful to the end user. It also serves some purpose from the portal provider's perspective, whether it is a public portal trying to attract web traffic to the site or an enterprise desiring to provide a central location for employees to obtain company information. Most portals and portal frameworks contain the concept of a "portlet" as a window to a specific set of content within the overall context of the portal page. Most portlets support the ability to customize the information displayed within this window. From the perspective of the portal framework, portlets tend to look and behave much the same as individual windows running in any windows-based operating system. They can be minimized, maximized and re-arranged to suit the individual portal user. From the developer perspective, a portlet is really a piece of code that plugs into a generalized framework. Different portal frameworks implement the concept of a portlet differently. In some cases, the portlet is a collection of JSP pages. In other cases, it may a special type of class that implements certain interfaces. Regardless of how it is implemented, the portlet is generally responsible for presenting a specific set of content that may be tailored to a user's preferences. The portal framework is responsible for handling the infrastructure services, such as providing the overall presentation, user management, security and personalization. When a user authenticates or logs into a portal, there typically is a set of characteristics of the portal that are tailored specifically to that user or users within a pre-defined group. At the very least, this would include which portlets are available to the user to display. For example, a regular employee logging into an employee portal may see the stock price of the company, company news, and even department news based on the group they belong to. A manager logging into the portal may see all these things as well as an expense authorization portlet that would list expense reports their employees have submitted that are waiting for approval. Associated with personalization is the ability to customize the portlets within the portal for a specific user that has logged on. This may mean choosing which portlets to display, how to organize them on the page and even the specifics of the content within the portlet. One final important concept associated with portals is commonly referred to as "skins". A skin is the idea that the portal can define a standard look and feel for all the portlets and the page the portlets are displayed on. This may include such things as background page color, font color, font type, special logos, etc. In many cases a user can choose a skin from a list offered by the portal provider. This concept is very similar to the ability to choose a desktop theme in the Microsoft Windows® environment. The developer perspective Considerations In thinking about adapting an existing application, or even creating a new application designed to be hosted in a portal, there are a number of important considerations. Before beginning any portalization effort, it is important to understand any design guidelines set forth by the enterprise or portal provider. These guidelines typically focus more on the look and feel than how navigation is managed. If the application is to be presented in an enterprise portal, the company will typically have enterprise wide guidelines that define how the application or content is to look within the overall portal in order to give the portal a unified presentation. Some aspects of the look and feel can be defined by the skin if the portal framework supports the idea of skins. However, developers of web applications will often hard code fonts and background colors in their presentation layer. To make it easier to adapt to a portal using skins, it is better if the definition of fonts and colors not be specified directly in the web application. It is also important to understand that typical web applications don't necessarily map easily over to a portal paradigm. This is especially true for web applications with multi-page interactions. It is important to understand the differences in navigation behavior inside a portlet as opposed to a traditional web application or web page. In a traditional web page, a user would typically select a link on the page presented in the browser, which would lead to another HTTP request returning a completely new page of content. While the behavior of a portlet within a portal may actually be the same, the goal is to present the impression to the user that only the contents of the portlet are changing. This presents a distinct challenge to the developer who typically has designed their web application navigation as a set of URL links that invoke ASPs, JSPs, Java™ servlets, or even static HTML pages. Now, they must think about how to specify navigation, not in the context of the web application, but from the perspective of the overall portal.

With this in mind, there are several factors that may impact the approach a developer might take in adapting or designing an application for portalization. The first is the support for portlet navigation within the portal. Some portal frameworks support the ability to define flow or interaction between pages that are routed through the portal manager as opposed to resulting in a direct HTTP request. In this case, it is important that an application being adapted or developed for a portal not use explicit URL links within their application since this would cause the browser to lose the entire portal context, reverting back to presenting a single web page. The second factor is the degree of personalization and customization the developer wants to support. For example, consider the simple QuizGame web application referred to earlier. In a typical browser scenario, the user might be presented with a login page where they would provide their player ID and possibly a password. Next, they would be provided a list of quizzes they can choose from. On selecting a quiz, they would be presented with a list of questions to answer and on submitting, they would receive a score. Within the context of a customizable and personalizable portlet, the presentation may be altogether different. Upon logging into the portal, the user might immediately see the list of quizzes because their player ID is tied to their portal login session. In addition, the user might choose to also be presented with their most recent scores, a feature that may not have been present in the original web application. Simple portlet integration Most portal frameworks provide a simple web URL portlet that simply invokes the given URL and presents the result in a portlet window. If this is all the integration that is desired, then the developer is essentially done. However, the goal of portalization is typically to offer certain content or application functionality within the context of the greater portal. In the example of the QuizGame application, it may be necessary to change the layout of the content to better fit in a smaller portlet area. Additional information may also be included, such as the top score for each of the supported quizzes, or links to trivia information sites could be included. If the application being adapted to the portlet is a web application and it was architected in a way that separates the presentation or view from the application functionality, it will typically be quite easy to adapt the application to a portal by simply modifying the presentation pages. The disadvantage to this approach is that once a user clicks on a link within the portlet, or enters information in a form that may invoke another URL, the result will be displayed in the full browser not the portlet. This is typically not the desired portal behavior. A better way would be to adapt the URL links to open a new browser window to display the result in. This at least has the advantage that the original portal contents remain more or less intact. However, the side effect of using this technique too much is an abundance of browser windows that the user must manage. Enabling sophisticated navigation within the portlet In order to present the appearance to the user that only the portlet they are interacting with is changing, it is necessary to use functionality that allows the portal framework to intercept the result of URL invocations and re-direct them to the portlet making the invocation. If the portal framework doesn't provide such capability inherently, it may be quite difficult to achieve this objective. However, if such capabilities exist, often it will be necessary to at least adapt the URLs in the presentation layer of the application. The following code samples illustrate the contrast between a traditional web page form and the same form adapted to work in portlet. <form name="form1" method="post" action="QGControllerServlet?action=login"> <b>PlayerId</b> <input type="text" name="playerId"> <input type="submit" name="Submit" value="Submit"> </form> Listing 1: Standard URL invocation within a web form <form name="form1" method="post" action="<portlet:createWebflowURL event="QGControllerServlet.event" doRedirect="true" extraParams='action=login'/>" > <b>PlayerId</b> <input type="text" name="playerId"> <input type="submit" name="Submit" value="Submit"> </form> Listing 2. Using the a JSP TagLib to generate a pseudo URL. The above example assumes that an event is created within the portlet development tools for the portal framework that would map the event "QGControllerServlet.event" to the desired Java servlet. This is typically a very product-specific solution since no standards exist to define portal behavior and navigation within a portal. Personalization and customization In providing personalization and customization for a portlet, there are two main areas to consider. The first is allowing the user to edit the properties of the portlet that may affect the content that will be presented. In

order to provide the ability to edit properties, typically an additional edit page needs to be defined as part of the portlet application that allows the user to change or add information. This is often done as a separate web page or JSP that would gather user preferences and store them back to the portal framework. In the QuizGame example, an edit page may allow the user to enter their player ID for accessing the game, as well as possibly choosing their 5 favorite quizzes to offer in the portlet. Typically, the portal framework will enable the ability to store portlet-specific properties such as those that can be accessed when rendering the portlet. It is up to the developer to decide what properties of the portlet to offer for customization and how they will use this information to present custom information in the portlet. This may also force the developer to go back to the application and add additional interfaces for obtaining the information in a way that supports the portlet presentation they are trying to provide. The second area of personalization that can be performed is in using information that is known about the user when they log in. This could be displaying group specific information or notices or a personalized greeting with the user's name. This is a relatively easy thing to do when the portal framework or portlet developer kit provides mechanisms for obtaining user specific information. Often, this is done by way of an API or Java TagLib. Application isolation and web services One other item to keep in mind is the degree of isolation desired for the application specific code. Typically in portals based on a J2EE application server, there is an assumption that the application code being referenced by the portlet is integrated into the overall portal code structure. This tends to blur the distinction between the portal code and the application code, which may not be desirable in cases where the application functionality is targeted at multiple user interface mechanisms where the portlet is only one of the interfaces. In this case, rather than looking to simply adapt an existing web application into a portlet paradigm, it may be worth considering re-writing the entire presentation and navigation layers (i.e. bypassing the JSPs and servlets). There are two clear ways to accomplish this. The first is to write or extend an existing portlet. From the developer perspective, a portlet is often implemented as a special class file that implements a standard portlet interface to a specific portal framework. This approach offers the greatest amount of flexibility to the developer, but also adds the greatest amount of complexity to the solution. Another way to achieve this goal is to modify the business logic layer to return information as XML documents. Most commercial portal products support a generic XML portlet that can retrieve XML documents and render them using mechanisms such as XSLT. However, this typically requires a significant amount of additional work to maintain extra code to support the various interface mechanisms for the same application. A better way to accomplish application isolation is through the use of SOAP based web services. Web services bring several key advantages to portals and portlets. The most significant is that they can be distributed virtually anywhere, including outside an enterprise that may be offering a portal inside the corporate intranet. The second is that since interactions with web services are done using SOAP, which is XML based, there is a great degree of flexibility in processing the information and rendering it to the portlet. Since web services often don't have a user interface, there is rarely a need to re-write the interface for a portlet. The challenge of this approach is in writing client components as part of the portlet that can locate and access the web service, using the defined web services interfaces to obtain the desired content to be presented in the portlet. It is usually not too difficult to write a specific portlet to locate and access a web service, rendering what it returns in the portlet presentation. However, to develop a portlet to do this in a generalized way, giving the developer some flexibility in how to present the results is much more difficult. In addition, if the interaction with the web service involves some sort of conversational state, the responsibility may fall on the portlet developer to maintain the state between invocations. Fortunately, many portal frameworks now provide web services portlets that will either provide generic access to a web service or allow the ability to extend it to provide custom access to a web service.

Tips for developing portal-ready applications So far, this paper has discussed portalization from the perspective of moving existing application functionality to a portal framework. If the developer is creating a new application or has the luxury of rearchitecting the application, there are a number of techniques that can be used to make the application more portal-ready. Use a model-view-control architecture The model-view-control (MVC) architecture is a way of grouping application functionality into three distinct categories, each serving a specific role in the overall application. Typically, the model represents the structure and organization of the data or content within the application. The view represents how that content will be presented to the client or end user. The control component represents how the user interacts with the application. As such the controller typically defines the flow and navigation within the application. The objective of using an architecture such as MVC is to allow the ability to isolate each of these functions so that it is possible to make changes to one component without significantly impacting the others. For example, a change may be made to the view aspect of an application without requiring any changes to either the model or the control modules. This architecture provides a distinct advantage in portalization. MVC based applications can be more easily adapted to a portal by simply making changes to the view and possibly the control code. Even if there is a certain business logic associated with the application, this can often be left untouched if it is not tightly woven into the view and control components. More specifically, an application can be adapted to the portal by first only changing the view. These changes are often superficial in order to adapt to a different form factor than may have been used for a browser. Then the control module can be modified or even replaced to suit the needs of navigation within the context of the portal. Use XML to represent content In web applications, XML is often used as a client neutral way of describing what will be presented. XML coupled with transformation technologies such as XSLT allow the ability to delay the decision of how to present the content until the last stages of processing where the results are returned to the requesting client. This allows the ability to tailor the presentation in very client-specific ways. In the context of adapting functionality to portals, this allows the ability to contain the definition of how the content is presented to a single mechanism, such as XSLT and the corresponding stylesheets. By doing this, it is easier to make changes to the presentation and navigation parts of the application without significantly impacting other parts of the application. In order to use XML in this way, the code responsible for controlling the behavior and interaction should be made to return XML rather than presentation-specific content such as HTML. Prepare to leverage the portal security mechanisms Portal security is a fairly complex topic and it is not within the scope of this paper to discuss security except as it may affect the individual applications being adapted to the portal. One key benefit of having a portal is the ability to sign on once to enable access to the applications that are offered within the portal. This concept is often referred to as "single sign-on". For applications that will be hosted in the same middleware infrastructure as the portal framework, it is much easier to leverage the same security mechanisms. Many portals use a standard HTTP cookie to store session information. In order to enable the ability to have single sign-on, it is important that all applications share the same cookie. Typically, this is done through configuration of the web application deployment descriptor. One thing to be careful of in building a web application is to not define a unique security scheme. Rather, the web application should leverage the existing infrastructure mechanisms as much as possible. For example, most J2EE based application servers support a number of security mechanisms for propagating user authentication and authorization information to the various components. Typically, portals that are built on top of a J2EE application server will leverage these same mechanisms. For applications that aren't co-located with the portal framework, it is often necessary to build bridging interfaces that can map the portal-specific security mechanisms to those of the application being adapted to the portal. Emerging standards for web portals Today, there is no standard that defines how the portal infrastructure should work, and no standard set of APIs for portlets, portlet navigation and customization. As a result, portlets developed for one portal framework will not interoperate with any others. There are two key emerging standards in this area that are important to be aware of. JSR 168 JSR 168 is a proposal submitted to the Java Community Process designed to define a standard set of APIs for portlets to plug into a J2EE based portal server. As would be expected, most of the portal solution vendors are involved in some way with this standard. JSR 168 attempts to address the problem of lack of portability for portlets across different portal frameworks. The goal of JSR 168 is to define a standard portlet API that developers could work from that would enable some degree of portability. In addition to standardizing the way in which portlets interact with the framework, the JSR also attempts to specify standard ways for portlets to share information and interact with each other. There is some acknowledgement in the specification that web services are an important integration mechanism for presenting application functionality within a portlet, but no clear direction on how that will play out. The current plan is to have a public draft of this specification available by December, 2002. The important thing to note is that most of the Java-based portal framework providers today have their own proprietary way of doing portals and portlets, but all plan to migrate toward the JSR 168 standard Java API as it is released.

The objective of Web Services for Remote Portals (WSRP) is to define a component model that would enable web services to be easily plugged into standards-compliant portals. The importance of a specification such as this shouldn't be minimized. According to one Gartner analyst: Web services need a producer and a consumer. Once the Web Services for Remote Portals standard is finalized, portals will become the chief consumer of web services, opening up a vast array of capabilities to portal users." [Phifer] WSRP isn't as much about defining the actual presentation of the web service user interface as it is defining a standard way in which portals could interact with the web service through the use of remote portlets. From the portlet developer's perspective, it is more likely that their focus would be on JSR 168 while the portal providers would be focused on supporting WSRP as the way to publish, locate and access remote portlets as web services (using SOAP and WSDL). The OASIS WSRP technical committee expects to have an initial specification released by December, 2002. The exact relationship of WSRP to JSR 168 remains to be seen, but it is likely that JSR 168 would represent the Java specific API used by WSRP enabled portlets to plug into the portal. Conclusions This paper has discussed a number of strategies for enabling an existing application to be adapted to a web portal (portalized). In doing so, the goal has been to provide the necessary concepts for a developer to plan for and ultimately perform the portalization. While the perspective has been taken of migrating an existing application to the portal, the same concepts can be used in designing a new portlet application. In this paper, a number of considerations were outlined that should be made before beginning a portalization effort:

WSRP

• • •

Understand what overall guidelines may exist for applications being hosted in a portal. Businesses often have a set of guidelines that offer a unified "brand" to outside customers and even for internal employee portals. Decide the navigation behavior of the application being adapted or created for the portal. Options could include leaving the portal context, popping up a new browser window or leveraging the portal navigation mechanisms if they exist to remain within the portal context. Decide how much customization the portlet will offer and how much personalized information will be leveraged. To leverage the user specific information often means using the portal framework mechanisms through the use of portlet APIs.

In addition, this paper has discussed a number of ways in which portalization can be achieved based on the decisions made. Some options include the following:

• • • • •

Simple portlet integration can be achieved by using one of the standard portlets supplied with the portal framework. If they exist, leverage existing portal navigation mechanisms to enable a more sophisticated portal experience from the end user perspective. Consider re-writing the navigation and presentation mechanisms to more fully exploit the facilities provided by the portal framework. Provide the ability to tailor the information presented in the portlet by adding edit features. This typically leverages the capabilities of the portal infrastructure for storing and retrieving portlet specific properties. Use web services as a way to achieve application isolation and enable a greater degree of plug-and-play capability.

It is important to note that moving an existing web application to a portal doesn't have to take place all at once. It can be a multi-step process. The first step is to present the existing content or functionality from within the portal. Once this is accomplished, the application will need to be better integrated with the portal such that it can leverage the portal navigation, personalization, and security mechanisms. Finally, the ultimate step in portalizing the application is to make it a web service such that the actual application functionality doesn't need to be co-located with the portal framework itself.

Sign up to vote on this title
UsefulNot useful