Java is a wide and far-reaching technology, and servlets aren't
the only way to build a dynamic web application. The portal
architecture is an alternative; on June 12, 2008, JSR-286, the Portlet 2
specification, was released. Like any new or updated technology,
its proponents are touting and marketing it in an attempt to
promote and attract interest. This can make it can be difficult to
separate the polished screen shots and buzzword-compliant
announcements from the substantive information that will make your
life as a developer easier.
Having spent the last few months since the specification was
released evaluating and working with JSR-286, I hope this article will
briefly introduce the concepts of the Java portal architecture;
compare and contrast it to standard Java-based web applications;
and then discuss the past and present, and offer my opinion on what I
see as its viability and future.
Other than knowing that the terms "portal container" and "portal
server" are used interchangeably, no portal background is assumed.
A familiarity with servlets will help in making the presented
concepts tangible.
The Portal Architecture
So what the heck is a portal? While the
word "portal" has become heavily overloaded in the software industry,
it does have two primary definitions. The first definition, in a
very generic and technology-independent sense, is a web-based
gateway, likely to multiple systems, where users are presented with
or can locate relevant content or information. Yahoo, iGoogle, and many
corporate intranets are all examples of this generic
definition.
The second and much more specific and concrete definition, as
well as the definition this article discusses, refers to a software
architecture where a server-side component is used to aggregate
content generated by small subcomponents called portlets. Unlike
servlets , which
are traditionally responsible for generating a complete HTML page,
a portlet only produces an HTML fragment. With multiple independent
portlets on a portal page, the portal server composes the generated
fragments of all these portlets into the full response, which is
then returned to the user's browser.
From the perspective of an end user, many web applications
emulate a portal (in the generic sense) and have a similar look,
feel, and function, and therefore it's important to clarify the
difference between "just" a standard web application and a portal
application. In Java, a web application is an application based on
the Java Servlet API. When you think of an application of this
type, whether the servlet API is used directly or indirectly
through some MVC framework (such as Struts or Spring Web MVC), what
you're thinking of is what I refer to as a standard Java web
application. A portal application uses the portlet API, which uses
the servlet API as its foundation, and in knowing this a portal
application can be thought of as a logical extension of a standard
web application. And just as a web application relies on a servlet
container that in turn uses the servlet API to invoke custom
developed servlets, a portal application relies on a portal
container that uses the portlet API to invoke custom-developed
portlets. The fact that a portal container relies on the servlet
API is largely hidden from the portlet developer, and it is the
underlying usage of the portal architecture and Java Portlet API
that distinguishes a web application from a portal application (in
the specific sense).
There are many architectural tradeoffs when choosing between
building a standard web-based or a portal-based application. In
building the former, your organization has total control and
flexibility over the design and architecture of each layer within
what will become your system. In doing this, you are assuming the
freedoms as well as the responsibilities of designing and
implementing both the application's architectural infrastructure
and the application's custom business logic. Along with this
control and flexibility comes the disadvantages that the
application will be a homegrown, in-house custom solution; that
this type of development can require developers with a great deal
of experience and expertise; and that building the application
infrastructure as well as the custom business logic will obviously
take more resources and time than if you were building just the
custom business logic itself. This is the typical "build it
ourselves" approach.
The portal architecture tries to change all of that. With the
goal of reduced development time and therefore reduced cost, a
portal server attempts to provide out-of-the-box implementations of
much of the common functionality that any web-based application
would require: role-based security (including authentication and
authorization), user registration and administration, self
resetting of user passwords, support for UI themes,
personalization, and customization are standard features. For
developers, writing custom software for the portal architecture is
dramatically different than for a web application. The premise is
to confine your custom development to the discrete portions of
individual functionality of each portlet and leave the previously
mentioned heavy lifting to the portal server itself. In essence,
you are choosing to write custom code only at the portlet level and
plugging those portlets into a prebuilt portal server in a "get
the application from a third party" approach. The portal server
market is fairly mature and several commercial as well as open
source portal servers are available for you to evaluate and select
from.
The Past: JSR-168
In 2001, portal architecture looked as if it could be the
next big thing. The technology had heavy hitters behind it and
appeared to be building solid momentum towards achieving critical
mass. But there were problems: there was no standardization of
portlet technology and there was no guarantee that a portlet
written for one vendor's container would run on a container from a
different vendor. To make things worse, there was also substantial
disagreement among vendors as to what services a portal server
should even offer. To solve this, in October of 2003 JSR-168 was
introduced into the Java Community Process (JCP), the official
organization overseeing improvements to the Java platform. JSR-168
standardized the services offered, the basic portlet programming
model, and the API,
which then ensured portlets were cross-vendor and -server
compatible.
The Present: JSR-286
While JSR-168 laid the foundation for the portal architecture, it
lacked many features that applications and developers needed. This
forced developers back into creating non-portable, vendor-specific
solutions, which therefore defeated the very purpose of having a
portal specification. Such was the state of Java portal development
until June 12th, 2008, when the specification for the next
generation of Java-based portal software, JSR-286, went final and
was publicly released. After nearly three years of development, JSR-286
was created to enhance JSR-168 and improve upon its shortcomings.
Some of the major enhancements of JSR-286 include inter-portlet
communication, WSRP 2.0 alignment, support for Ajax, and portlet
filters and listeners.
The Road Ahead
With the release of the new features and functionality of
JSR-286 and with the Java community seemingly willing to take a
fresh look, the question is whether we are we going to see a
significant increase of interest, a rise in popularity, and a
resurgence of the portal architecture. With nearly ten years of
professional experience with both web- and portal-based projects and
having done multiple portal projects as recently as 2007 and 2008,
I've spent the last few months evaluating JSR-286 and the portal
architecture. Unfortunately, it is my opinion that for many
reasons JSR-286 (and portal architecture in general) is a layer
of complexity over servlets that doesn't provide enough benefits or
technical "bang for your buck" to warrant an increase in adoption
or a large-scale impact on the Java landscape.
The portal architecture's central concept and greatest strength,
the portlet, remains its greatest weakness. Although confining your
development to a portlet frees you from many application-level
issues, it is overly restrictive. While there is nothing you can do
in a portlet that you can't do in a servlet, the inverse is
definitely not true. Developing an application-level feature at the
portlet level is an awkward development task and typically results
in the modification of the portal server software itself. But by
modifying the portal server, you tie your project to that vendor's
product, and by no longer confining your development to the scope
of the portlet API, you are no longer JSR-168/286-compliant.
Many new portlet features either have long been available in
servlets or simply solve portlet-specific issues. While narrowing
the long existing gap with servlets is a good thing, it begs the
question: when you start your next application, why wouldn't you
just use servlets from the start?
With its render request, action request, and more complex
lifecycle, a portlet is a different animal than a servlet, and
finding developers experienced with portlets has been a significant
challenge on every portal project I've been a part of. In fact,
I've never been on a project that was able to hire a single
developer with previous portlet experience. Instead, they all
brought on developers knowing they'll have an initial learning
curve that's higher than normal. In sharp contrast, finding developers
with a background in servlets has never been a problem.
Then there's the matter of the timeline of portlets. The portlet
concept, having been conceived in the late '90s and early 2000s,
came about when web-based application development, the Java
open source community, and even Java itself were all in their
infancy. At that time, starting a new application typically meant
starting nearly from scratch. Today the situation has changed
dramatically: with a wide range of available MVC and security
frameworks, ORM and templating tools, and a seemingly limitless
supply of other mature open source software, a development team can
quickly build an application that rivals the features of an out-of-the-box portal application in short order. The portal
architecture's primary benefit of reduced development time has been
marginalized and is just as available and obtainable for
applications built through custom design and development.
In many ways, the the portal architecture reminds me of EJB in
that both can be viewed as a monolithic all-or-nothing approach
that dictates an overly large portion of each application layer's
design. While EJB was once king in the last half decade, Java
itself has undergone a tremendous amount of change. There has been
a fundamental design shift (which, rightly or wrongly, is largely
credited to the Spring framework) toward layering, separation of
concerns, simplification, and most importantly an a la
carte, "use only as much as you need or want" attitude toward
technology. Gone are the days where just because you wanted to wrap
your business logic in a stateless session bean you need to use a
full Java EE application server, embrace JNDI, and create local,
home, and remote interfaces as part of your domain model.
Similarly, the portal architecture -- where the integration,
service, and presentation tiers have been designed and built for
you -- has not caught on as has the usage of frameworks and tools
focused and specialized to each specific tier. If you are willing
to acknowledge that it was this monolithic all-or-nothing design
philosophy that lead to EJB being essentially rejected
by the Java community, it is also reasonable to think that the same
philosophy has and always will significantly hinder the portal
architecture.
Back to the Future
Personal experience and opinions are relative and subjective.
Realizing that most technical audiences are fact- and logic-oriented,
I did some research to help support my position.
In 2003, the list of the 24
organizations officially supporting JSR-168 included Accenture;
the Apache Software Foundation; BEA; Boeing; Borland; Bowstreet; Cap
Gemini Ernst & Young; Citrix; Computer Associates; CoreMedia;
DaimlerChrysler; Documentum; Enformia Ltd.; Hewlett-Packard;
Interwoven; Macromedia; McDonald Bradley; Novell; Oracle; Plumtree;
SAP; Sybase; Tarantella, Inc.; and Vignette. Today the list of the six
organizations officially supporting JSR-286 is BEA, IBM,
Oracle, SAP, Sun Microsystems, and Vignette. That means that 18 out of
24 (75 percent) organizations that officially supported JSR-168 in
2003 do not officially support JSR-286 today.
According to the official website, JSR-168 was introduced into
the JCP in May of 2002 and reached a status of "Final Release" in
March of 2006. Based on those dates, it's logical to assume that
JSR-168 is built on J2EE 1.3 which, according to its official
website, was introduced to the JCP in February of 2000 and reached
a status of "Final Release" in September of 2001. That means that
if you are doing JSR-168 development, and you strictly adhere to
the specification, you are building your applications to the latest
and greatest Enterprise Java technology of 2001.
Digging deeper, the facts are just as discouraging about
JSR-286's recency and relevance. Section 2.1 of the official
JSR-286
specification, in describing the specification itself, states
that "the main goal of [JSR-286] is to align the Java Portlet
Specification with J2EE 1.4, other JSRs relevant for portlet
programming, like JSR 188, [and] the next version of Web Services for
Remote Portlets (WSRP)." According to Sun's official JEE 1.4
website, EE 1.4 was introduced to the JCP in October of 2001 and
went into a status of "Final Release" in November of 2003. The
official JSR-286 website shows that it entered the JCP in November
of 2005 and went into a status of "Final Release" in June of 2008.
Reading between the lines, this means that the stated primary goal
of the recently released JSR-286 is to align itself with the latest
and greatest Enterprise Java technology of 2003.
Conclusion
Professional hands-on experience along with the above research
led me to the conclusion that the portal architecture lacks
enough technical advantages and distinguishing features to warrant
an increase in acceptance. In practice, few applications can
constrain themselves to the isolated and disparate functionality of
portlets, and relinquishing this degree of architectural control is
unrealistic in enterprise-level software. While at one time
portal architecture did possess a great deal of potential for
widespread adoption outside of trivial applications and niche
markets, potential is only good if it is maximized and delivered
upon. Despite the recent release of JSR-286, I think the elephant
in the room is that the portal architecture's window of opportunity
to become a mainstream technology has not only closed, but closed
quite some time ago. While it would be foolhardy for me to suggest
that the portal architecture couldn't be put to good use under any
circumstances, be cautious: it is intended to solve many problems
for many different people and rarely is there a software package
that is truly a one-size-fits-all solution. If using the portal
architecture feels like anything less than a perfect fit, it is
likely an early warning of trouble ahead and customizations, no
matter how slight, are the first indication that it may not be for
you.
I'll stop short of saying JSR-286 is dead on arrival and instead
simply say that while it is a welcome step forward for those
currently doing JSR-186, I believe JSR-286 will not be able to
reverse the negative momentum, and portal architecture will
continue its well-established decline toward (and eventually over
the edge of) irrelevance.
Resources
Eric Spiegelberg is a Minneapolis-based Java/EE consultant specializing in Spring, Hibernate, and web-based software development.
Couldn't agree more