JSR-286: The Edge of Irrelevance Blog


    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 rejectedby 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.


    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.