Open Source Portals

makeshiftluteΛογισμικό & κατασκευή λογ/κού

14 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

362 εμφανίσεις

Open Source
by Brian J. Dooley
Enterprise portals are becoming an
increasingly important tool in the
integration of data access and
applications, in providing a platform
for convergence of numerous dif-
ferent services, and in supporting
and enabling collaboration. The
portal market now includes an
array of players, ranging from mas-
sive development frameworks such
as IBM WebSphere to simplified
portals for smaller businesses and
peripheral operations as well as
portals dedicated to specific func-
tions. While IBM, Microsoft, and
BEA have achieved some degree of
dominance at the high end, much
of the portal space remains up for
grabs. This is significant in that
corporations will most likely adopt
and possibly integrate a number of
different portal infrastructures; this
is being simplified by the Java
Specification Request (JSR) 168
and Web Services Remote Portlets
(WSRP) standards.
Open source portals represent
an interesting alternative to com-
mercial portals and compose an
important percentage of recent
deployments. Their appearance
and success derive from the new
standards that allow them to inter-
operate with commercial portal sys-
tems and take advantage of portlets
being developed for major portals.
If they fit requirements, open
source portals can provide consid-
erable cost savings and maximum
flexibility in implementation. They
are not for everyone, however; and
they require careful evaluation of
both existing IT skills and infrastruc-
ture requirements. Otherwise, the
result could be expensive and
fraught with problems.
Open source portals are generally
based on Java technology and are
heavily standards driven. They
take advantage of the JSR 168
and WSRP portlet standards,
which define portlets and how
they are integrated into a portal
system. Open source licensing
means that source code for these
implementations is available for
free and, importantly, can be
freely modified provided that
modifications are shared. Many
open source products can also be
purchased in binary form, but pur-
chasing price is minimal. The cost
lies in consultation and support,
which, for infrastructure-level sys-
tems such as portals, can be formi-
dable. But support requirements
are heavily dependent on an orga-
nization’s existing skill levels.
Pushed forward by the growing
needs for integration and collabora-
tion, by the need for even cash-
strapped organizations to integrate
applications and support collabora-
tion, and, importantly, by standards,
open source portals now exist in
abundance at every level of com-
plexity and to suit a variety of
Business Intelligence
Advisory Service
Executive Update
Vol. 5, No. 6
special purposes. Although a num-
ber have been built specifically for
the enterprise, it is fair to say that
most were created to support non-
profit organizations and academia
and to provide collaboration and
single-point access for open source
software development projects.
The use of portals in developing
open source software projects is
of special interest, because these
projects often involve hundreds of
programmers and vast amounts of
content. They absolutely demand
high levels of collaboration. Portals
that can prove themselves in this
environment should easily meet the
more modest needs of most enter-
prises, though connection with
back-office applications remains
an issue.
Standardization is critical to the
future growth of both commercial
and open source portals. Portals
have developed an infrastructure
that generally provides a portal
server, which offers services to
clients (generally browsers); a
portlet container that interfaces
between portlets and the server;
and the portlets themselves, which
provide the connection to specific
applications and services.
At present, the most important
standards in this environment are
JSR 168 and WSRP, which define
how services are connected.
Figure 1 displays the basic portal
JSR 168 is a standard specifying a
set of APIs for portlets and provides
standardizations that enable inter-
operability among portlets and por-
tals. Any JSR 168 portlet developed
for one portal server should be able
to run on another portal server.
Created by OASIS, WSRP is a stan-
dard that defines the interface and
semantics for a Web services stan-
dard to connect plug-and-play of
portlets with portals and other
“aggregating Web applications.”
It permits content to be hosted in its
native environment, and it is specif-
ically useful in connecting portlets
between different portals. It differs
from JSR 168 in that a portlet server
is not necessary to serve WSRP-
compliant content; it can be pro-
vided as any Web service would be.
JSR 168 and WSRP operate at dif-
ferent levels. JSR 168 specifies how
a portlet attaches and interacts with
a portlet container, while WSRP
specifies how to access portlets
across portals. The development of
these standards has provided a
degree of interoperability among
portal systems that support them,
enabling the creation of an environ-
ment that unifies portal infrastruc-
ture. Within this environment, open
source portals are likely to provide
the greatest benefit, handling tasks
outside the reach of commercial
portal systems and linking them to
a unified portal environment.
Vol. 5, No. 6 ©2005 Cutter Consortium
Remote Portlet
JSR 168
JSR 168
Figure 1 — Basic portal infrastructure.
The chief advantages of open
source portals are the following:
 Trialability. Since they cost
nothing to obtain, it is possible
to experiment with many alter-
natives without incurring any
costs other than time spent in
the trial period.
 Low acquisition cost.As open
source products, acquisition
costs are minimal.
 No proprietary lock-in. There’s
no requirement to use a single
portal infrastructure system or
OS; integration isn’t limited to
specific applications.
 Standard support. Open
source portals are likely to be
standards driven.
 Active support community.
These products are hot, and the
major open source portals have
developed active discussion
communities that debate and
respond to questions on imple-
mentation, security, extension,
and integration.
However, open source portals
also raise a number of significant
 No one has ultimate responsi-
bility. There’s no one to blame
if the project goes wrong, and
it’s unlikely that there will be a
vendor to clean up the mess.
 Support costs can be high.
Some of these products require
substantially more coding and
configuration than commercial
products. Changes must be
documented and maintained
through the lifecycle of the
product, which can result in
high costs.
 Lack of immediate solutions.
While portlets providing an
interface to common applica-
tions may be available, locating,
connecting, and testing portals
to get it right is likely to be a
laborious prospect. There is no
out-of-the-box solution.
 Lack of good documentation.
Documentation in open source
projects is often low grade or
lacking, which can make con-
figuration difficult.
 Uncertainty regarding future
development. There are no
guarantees that the project
under open source develop-
ment will continue. This is offset,
however, by strong standards
There are numerous open source
portals, and it is impossible to
adequately survey the market
due to the nature of open source.
Important open source portal proj-
ects include the following:
 Jetspeed
 Liferay
 Red Hat Portal Server
 GridSphere
There are many others, but these
products have achieved significant
followings and provide a represen-
tative sample.
Jetspeed. Now in version 2,
Jetspeed is from the Apache
Software Foundation, which pro-
vides the open source Apache Web
Server. Jetspeed is a customizable
portal based on Java and XML.
Jetspeed-2 offers a number of
architectural enhancements over
Jetspeed-1. Providing additional
support for Jetspeed is CHEF, the
CompreHensive collaborativE
Framework, a J2EE-based appli-
cation server that incorporates
Jetspeed and collaborative tools.
Liferay Portal Enterprise. Liferay
is designed as a customizable
portal to deploy JSR 168 Java
portlets. It contains a variety of
portlets for mail, document library,
calendar, and message boards. It
was developed for a church group,
which has enhanced its collabora-
tion focus, but internal biblical links
and other church-related features
may put off commercial users.
Red Hat Portal Server.Red Hat’s
contribution, this open source por-
tal supports multiple languages in
its user interface and a variety of
document standards including WAP,
XHTML, and VoiceXML. It is signifi-
cant given Red Hat’s dominance in
the Linux space.
GridSphere. GridSphere is a JSR
168 API–compliant portal system
that offers near-complete compati-
bility with IBM WebSphere. It is one
of the more complex open source
portal offerings. Features include
high-level model creation, built-in
support for role-based access con-
trol, and localization support for a
number of different languages.
Other open source portals include
eXo, oPortal, jPortal, OpenPortal,
basicPortal CMS, Stringbeans, JBoss
Nukes, Gluecode Portal Foundation
Server, uPortal, Jahia (collaborative
source rather than open source),
and Cocoon portal framework.
As enterprise portals have grown
in importance, the alternatives for
implementations have proliferated.
Alongside the commercial options,
many open source portals have
been developed that offer a wide
range of complexity levels and suit-
ability for different purposes. Open
source portals provide a viable
alternative to commercial products,
but they must be evaluated and
implemented with care.
Key issues include existing staff ’s
IT skills, fit with existing infrastruc-
ture and applications, and the
size and complexity of the imple-
mentation project in comparison
with the requirements for a com-
mercial project. It is important to
consider the total cost, including Vol. 5, No. 6
4 Vol. 5, No. 6
development, customization, and
ongoing maintenance.
Open source portals are not for
everyone. They do need to be
considered, however, if only to
provide a basis against which
commercial portal applications
can be evaluated.
Brian J. Dooley is an author, ana-
lyst, and journalist with more than
20 years’ experience in analyzing
and writing about IT trends. He
has written six books, numerous
user manuals, hundreds of reports,
and more than 2,000 magazine
features. Mr. Dooley is the founder
and past President of the New
Zealand chapter of the Society for
Technical Communication. He initi-
ated and is on the board of the
Graduate Certificate in Technical
Communication program at
Christchurch Institute of Technology,
and he is on the editorial advisory
board for Faulkner Technical
Reports. He can be reached at
The Executive Update is a publication of the Business Intelligence Advisory Service. ©2005 by Cutter Consortium. All rights reserved.
Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law. Reprints make an excellent
training tool. For information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail service@