Recently, the first formal request for a new standard concerning the API
between portals and portlets was submitted to the Java Community Process for
Java Specification Request (JSR) 168 proposes a standardized interface
that allows so-called portlets to be written in a way that makes them
universally applicable across all portals from all vendors. Once realized,
JSR 168 will have a far-reaching impact and will represent a significant
step forward in defining portlets as a prime interface to Web services,
which can be conveniently aggregated and personalized within portals.
To understand the long-term consequences of JSR 168, it's useful to
review the role of both Web services and Web-based portals in the
development of application software targeted at the Internet. The concept of
Web services has energized the realm of application development by providing
a new type of Web-based platform that connects users and widely distributed
applications residing on servers. Web services are generally defined as
modular, encapsulated functions that can be loosely coupled to provide
specific results to an end user either an individual, an application, or
even another Web service. The continuing growth of the Web has created the
potential for precipitous growth in Web services and a nearly infinite
combination of interactions between services and users of all types.
But in another sense, Web services has created an embarrassment of
riches for IT professionals. Without some way to anchor and focus Web
services for the benefit of specific end users, their productive impact will
be severely constrained. A very practical solution to this problem is found
in the Web-based portal, a well-established entity that aggregates and
organizes multiple streams of information produced by applications
distributed across the Web. The recent profusion of enterprise-level portals
has already demonstrated their value as an organizing framework for Web
services at all scales of operation, from end users to departments and
enterprises. In every case they bring coherence to a potentially
overwhelming and chaotic flow of information.
While the portal represents the client side of solving the Web services
problem, it obviously requires a complementary entity on the server side.
This need is now being filled by a software component called the portlet,
which owes much of its technical ancestry to the servlet.
In earlier phases in the evolution of the Java Virtual Machine (JVM),
the original intent was to have platform-independent code that would execute
on the client side in the form of applets. However, over time, the concept
of platform-independent Java execution migrated onto the server side, where
the majority of an application's execution occurs, leaving the client to act
more in an interface role. Hence, the emergence of servlets.
A portlet further extends this concept by having a Java-based
application execute on the server side and then present the user with a
highly flexible interface that resides within the graphic real estate of a
portal, which treats the application as one of many interactive channels
presented to the user at any given time.
The coupling of portlets to portals, which act as organizers/aggregators
of portlet content, offers significant potential to the developer community,
technically and economically. From a technical standpoint, the portal
represents a good generalized software framework to guide the course of
content development. Its infrastructure provides a number of attributes that
support the tactical details of content delivery and presentation. These
include items such as single sign-on capability; flexible and extensible
authentication; management of policies via identity; device identification;
distributed session management; and the ability to deliver content across a
wide array of end user devices, such as desktop machines, cell phones, PDAs,
From an economic standpoint, the portal represents a convenient and
clear way to organize the market for portlet content. Enterprises,
organizations, and service providers will use the portal as a highly
flexible vehicle to package services in ways that represent the specific
requirements of various user communities.
However, to realize the full potential of portals and portlets, one last
barrier remains, and that's where the proposed standard comes in. While the
general concept of a portal is well understood and accepted, this belies a
great deal of diversity in the way portals are technically constructed and
how they interface with portlets. Consequently, developers must currently
pick a target portal and write code aimed specifically at the execution
environment defined by that particular one. JSR 168 seeks to remedy this
situation by defining an API that universally dictates the interface between
all portals and portlets across the Web.
While there are numerous details within JSR 168, it's worth considering
some of the highlights that show the potential benefit of the proposed API.
Most fundamental, with the formalization of the portlet API, the
specification request officially defines a new atomic unit of execution
within the Java arena, in the same way that JavaBeans, applets, and servlets
are recognized. This concrete definition of a portlet gives programmers a
clear frame of reference to guide their programming efforts. At the same
time, it provides a client-agnostic programming interface that extends
across all end-user devices with full provisions for declarative security
and remote execution.
With the API specified by the proposed standard, portlets would have
well-structured, predictable access to their host portal environment. For
instance, they would be able to obtain and act upon user profile information
provided by the portal. They would also be able to dynamically interact with
the portal window and action event model to make the best use of their
allotted real estate on the portal page at any given moment. They would also
have a stable model for managing configuration (personalization) on a
per-user basis. At a higher level, the API would allow portlets to interact
with other portlets within the same portal environment through data sharing.
For a standard such as this one to gain broad acceptance, it must
deliver benefits that extend through the entire value chain of the Web
services industry, and a quick tour through this chain shows that JSR 168
will have consistently positive impact. Upstream, at the IDE level,
toolmakers will have an opportunity to expand and remarket their current
offerings to embrace portlets as a new atomic unit of execution. For
instance, with a standardized API, it will become possible to automatically
derive portlets from other applications via a new type of IDE tool.
Further downstream, developers will have a significantly expanded market
opportunity because their applications will be freed from the confines of
specific portal requirements. Writing to these ever-changing interfaces
consumes a large share of development dollars that could otherwise be put
into new content.
Once new content becomes available, portal providers will have a wide
range of options in configuring the information flow on their portals. Right
now, providers must individually construct and maintain the interface for
each service occupying space in their portal environment. With JSR 168
enacted, the standardized interface will substantially reduce the time and
cost of integrating and supporting Web services packaged as portlets.
At the enterprise level, the proposed standard promises to streamline
the process of delivering specific applications to users throughout the
organization. Once the standard is in place, all application vendors will
have a single target for portlet development, and can routinely provide a
standards-compliant portlet as part of the application itself. Also, the
process of deploying portlets will be greatly simplified and can easily span
portal products from multiple vendors, if necessary.
Perhaps the biggest benefit comes at the far end of the chain for the
user accessing a portal from a desktop or mobile device. When JSR 168 is
fully implemented, portal users everywhere will finally realize the full
benefit and richness of the portlet as a primary point of entry into the
domain of Web services.
JSR 168 operates in the great tradition of technology standards that
shift market competition from proprietary lock-ins to a contest based on the
best implementation for the broadest set of users. While it may produce some
short-term disruptions, the long-term result is a major win for everyone
On Portals and Portlets
Over the past couple of years, portals have come to play a key role in
the delivery of applications, content, and, more recently, Web services. In
general, a portal can be defined as a highly personalized Web site providing
secure access to applications and business processes that the portal user
shares with well-defined user communities on both sides of the firewall. All
services delivered to the portal are based on a set of roles, permissions,
and preferences assigned to the individual portal user.
For example, an engineer working on mechanical systems might have a much
different portal configuration than an accountant assigned to inventory
control within the same enterprise. Also, users have the latitude to extend
beyond their portal's initial provisioning of applications and data and
personalize its environment to suit their particular working style. At the
same time, the portal should be able to support a full range of client
device types and even different physical locations for the user. In terms of
IT infrastructure, portals must be integrated with a number of other
software components, including directory servers for user management and
application or Web servers that provide a conduit to applications, data,
reports, and transactions.
Portlets, on the other hand, connect to and display applications of
various sizes and scopes that execute independently from the portal, but use
the portal as either a dynamic or static interface to the user. In effect,
portals can be thought of as collections of portlets. The permission to use
these portlets is defined by the user's role in a given community, and is
managed by the portal's interaction with various directory services.
Multiple portlets may be running and even interacting within a user's
portal at any given time.
Stuart C. Wells is senior vice president of iPlanet Products and is
responsible for the iPlanet product
development and product marketing functions. Stuart holds a BS in
electrical and electronic
engineering, an MS in digital techniques, and a PhD. in video and image
compression, all from Heriot-Watt University in Edinburgh, Scotland. Stuart
also earned an MBA from Santa Clara University, California, and attended
Stanford University's Executive Business Program.