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 re-
programming 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 re-
architecting 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.
WSRP
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:

• 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.