Академический Документы
Профессиональный Документы
Культура Документы
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.
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.
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.
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.
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.
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:
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.
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.
• 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.
• 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.
• 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.
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.
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.
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.