Skip to main content

JSR-286: The Edge of Irrelevance

January 20, 2009

{cs.r.title}







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, "http://jcp.org/en/jsr/detail?id=286">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 "http://en.wikipedia.org/wiki/Web_portal">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 "http://en.wikipedia.org/wiki/Portlet">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 "http://portals.apache.org/pluto/portlet-1.0-apidocs/">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 "http://today.java.net/pub/a/today/2004/06/15/ejb3.html">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 "http://jcp.org/en/jsr/detail?id=168#orig">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


width="1" height="1" border="0" alt=" " />
Eric Spiegelberg is a Minneapolis-based Java/EE consultant specializing in Spring, Hibernate, and web-based software development.
Related Topics >> JSR   |   Programming   |   Web Development Tools   |   

Comments

Couldn't agree more

As a web developer for the past 5 years and doing portal development for 2 years I can't agree more with your post. I have a feeling that portal development may be relevant as an intranet application but will not ever be the next big thing for large scale development. The concept is nice but there is a layer of complexity like you say when once dig deep into security, personalization within a portal. That where I think the standard just chokes. Along side with JSR286 is wsrp spec from OASIS. It doesn't go anywhere far either. I used wsrp4j for awhile until I couldn't stand the dormant status of the project. I dropped it and go with OpenPortal implementation. Both clamming they're reference implementation but trust me, it's not working out of the box switching from one to another. In the non-free landscape things are not looking great either. BEA WebLogic portal is a mess (non-standard, slow in performance). I haven't had a chance to work with IBM portal.

I am looking at using RAP instead

I have been doing some work with RAP. I do "desktop" UIs too so it works out nicely. And since it uses OSGI, ...

Alternatives?

Having written a JSR168 container myself, and a whole bunch of portlets, I can see some of the issues you refer to. But, what are the alternatives? If you need to aggregate functionality on a page, without using portlets, what options are available?

Excellent article

I have been waiting for someone to post an article like this and this should be made mandatory reading for all architecture astronauts and portal project managers. @rickardoberg - I see a couple of alternatives, for example a site like NetVibes is made possible with some nifty javascript aggregating content pulled from POX / JSON services. I also think Apache Wicket is the best option for Java developers because of how you can compose pages out of multiple components. It takes very little thinking or effort to design a component that will contribute an HTML fragment (including proper header css / javascript) to a web page - and loosely coupled from the execution context. Things which the portlet spec makes such a big deal of such as "inter portlet communication" are trivial to implement because of Wicket's approach of working in pure Java. You can look at the project as an example of what's possible.

Excellent article

Sorry, last sentence in my previous comment should be: You can look at the Brix project as an example of what's possible.

tin foil hat?

well constructed argument, but i think there is more at play. the argument does not account for the perspective or power of the end-user. the lack of traction of the JSR-168 specification is directly related to the barrier to adoption, and that is two fold: 1 - commercial vendors have never had any incentive for standardizing their platform or framework for content delivery 2 - developers have never had strong reasons to design modularized user interfaces the onslaught of mobile devices forces a shift in this space. commercial vendors now have a market for selling the individual applications that used to make up there proprietary suite of applications, and developers are being forced to to design modularized user interfaces in order to reach their users. it seems that this could change the way vendors do business, if they start to ask the question, "how to we get our applications to users on their phone?". this could be pie in the sky... however, if this led to vendors decoupling themselves from their proprietary framework for application delivery to begin profiting in sale of applications outside their framework, then this could be the slippery slope into removing themselves from the business of providing that framework for delivery... at the same time mobile applications could create a movement among developers to design one user interface for delivery via phone or browser. many developers hate user interface design anyway, so designing one that fits both needs could be an easy sell. ... the mobile revolution could be the catalyst for further portal adoption. this path could lead both of them to the now maturing standard for page fragment delivery, JSR-286. And more importantly, embracing community source solutions that are way ahead of the curve in the implementation of containers that deliver on these standards (i.e. JASIG uPortal).

Application Integration

A portal does not just have the goal of "reduced development time and therefore reduced cost". An important goal is making it possible *at all* for independently developed applications (e.g. by different departments) to work together on the same site in a reliable manner. If you have the politicial power to convince all departments of an enterprise to use the same open source framework, that's fine. But in practice, the "limitless supply of [...] mature open source software" becomes a liability - different players within the enterprise will prefer theirs. Having an industry-backed standard for presentation-level application integration helps a lot, especially when it has bridges to a lot of relevant MVC frameworks. On "industry-backed": Counting "supporters" on the JCP list is a rather weak argument - I think CoreMedia did not do JSR168 at the time it was on the list, while now it does JSR286 without being on the list.

my rule of thumb is avoiding portal projects...

The portlet API puts too much constraints for web development. IMHO these contraints come from putting enforcements at API level, enforcements that come from the architecture (meta)level. Then, it looks like things are frozen. It's cumbersome, too far away over traditionnal web development. And the portlet web development does not take benefits from other efforts from the more traditionnal web development. Oh, and, portlet portability is quite a BIG joke. That is, the portlet API just pushes the problem 1 or 2 meters away, but the problem is just still here. Portlets don't live in dreamland, they just use services, and often (proprietary) portal services. Andy Pemberton was right complaining about [the spec] being a “portlet spec, not a portal spec”. I would rather prefer a spec specifying portal pieces, like SSO, communication bus, conversation context... instead of a portlet spec. IMHO, a portal is just a sophisticated home page, with multiple content and SSO. I don't buy constraining myself into portlet technology for an entire project, while only the home page may need that technology ! My personal rule of thumb is avoiding, whenever I can, working a portal project... Other alternatives look like existing or coming, like widgets or OpenSocial : Goodbye JSR-168 and WSRP portlets… Hello OpenSocial gadgets! http://blogs.alfresco.com/wp/luissala/2008/12/09/goodbye-jsr-168-and-wsr... Widgets vs. Portlets http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/

Why JSR-286 is irrelevant and how to fix it

I have blogged my thoughts about this. In a nutshell, I think this is actually a business problem. Portlets do not have a strong business case. http://portalzone.blogspot.com/2009/02/why-jsr-286-is-irrelevant-and-how...