Why JSR-286 is irrelevant and how to fix it

Today I came across an interesting article on java.net :JSR-286: The Edge of Irrelevance. It also seems to have sparked some discussions in the community: In response to JSR-286: The Edge of Irrelevance.

In the java.net article, the author talks about how the Portlet spec is losing it's edge and makes his point by listing the number of organizations supporting the spec (for Portlet 1.0 it was 24 and for Portlet 2.0, it is just 6). He also goes about explaining the "higher than normal learning curve" for portlets and the "monolithic architecture" that portlets dictate. The community discussions around this article also seems to focus on the same lines : bad design, too much of constraints etc.

However, in my opinion, the reason why portlets are getting irrelevant is something different.

Portlets focus on solving one part of the problem, the integration of UI (it doesn't solve this very well either) between the portal and the portlets. However, it has no notion of standardizing on the data it operates on. For example, there is no reliable way for portlet to get the email id of a user who has logged in into the portal and viewing the portlet.

What sort of real-world, portable, business applications would you expect developers to build with such restrictions ? The most important aspect of a Portal is not only it's aggregation abilities but also the data that lies underneath. Yet, the portlet spec does not have any notion of portal data.

Therefore the only portable portlets that you can realistically build is a stock ticker or a weather portlet. Any portlet that is built to actually use data from the portal becomes proprietary.

The "fix" is to come up with a standard that can actually helps portlets (or "applicationlets" as I would like to call it ) to be able to query the portal for it's data. This is not something new. This is how third party developers build applications on Facebook and Myspace (on the enterprise front the Zoho Marketplace is a great example). These applicationlets are provided with an API that can query Facebook/Myspace about the details of the user who is viewing it, get the users friends, message them etc. That is all that is needed for developers to come up with interesting social apps.

So, let us assume that the portal vendors define a standard to akin to OpenSocial. Let's call it OpenEnterprise. All OpenEnterprise applicationlets must have the ability to query the details of an employee who is using the portal (email id, employee number, etc), query the employee's boss, query the employees subordinates if any, message any employee in the organization (via IM, email) and perhaps post documents, spreadsheets etc on behalf of the employee.

This would be enough to provide a platform to build a rich set of portable enterprise applications: Time sheets, Reporting tools, HR tools , you name it. It will also encourage developers to build apps that can integrate deeply with the portal and not just superficially. Portal vendors will start supporting the spec because of the rich set of applications that can be made available to the users. Third party vendors are bound to pop-up, building specialized business applications that can actually be plugged in to your portal and developers will learn the spec even if the programming model is not perfect !

In short, this is actually a business problem, not a technology problem.

Portlet 2.0 on JBoss

Packt Publishing recently published "JBoss Portal Server Development". The books covers Portlet 2.0 on JBoss. Grab the free sample chapter here : "Portals and Ajax" and let me know if you find it useful.

My Javaworld Article - Portlet 2.0 Quickstart Guide

I just published a new article in Javaworld titled: A quickstart guide to Portlet 2.0. It talks about how get up and running your first portlet on the JBoss Portlet Container.

Makes a good addition to the Portlet 2.0 (JSR 286) Tutorial series.

JSR 286 - Too little , too late

Just noticed that the JSR 286 spec has been finally posted : JSR-286 Now Posted. As you can see, the Expert Group for this spec was formed in Dec 2005. And it has taken 2.5 years for the EG to iterate to the next version. Portlet 1.0 was released in 2003, 5 years back.

My personal opinion is that this technology has been delayed to almost a point of irrelevance. And it would be interesting to see if Portlet 2.0 will succeed to make an impact.

Portlet Tutorial - Anatomy of a portlet

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series

Now that we have written and successfully deployed our Hello World portlet, let's understand it's various components.Here is how our portlet would look when deployed in a container.


Notice how the portal has created a distinct boundary or window for our portlet. This is called a Portlet Window. Each portlet is visually contained in a portlet window. In addition to the portlet content (i.e the "Hello Portlet 2.0 World" message that we printed in the render method), the portlet window also contains the portlet title (we mentioned this in the portlet.xml) and some click-able controls called decorations. These decorations help control two different aspects of a portlet - modes and window states.

Portlet Modes and Portlet Window States

At any given point in time, all portlets can defined by in terms of two unique characteristics - what the portlet is currently doing and how much space the portlet is taking up on the page. The Portlet Mode defines what the portlet is currently doing. The Portlet Window State defines how much space a portlet takes up in a particular page.

For example, we could have written a help message for the Hello World Portlet and displayed it when a user clicks on the Help button (the decoration with a "?" symbol). In this case the portlet would be in the "Help" mode. Similarly we could have written different "Hello World" messages based on how much space the portlet occupies on the page. This is possible because in each case, the portlet would be associated with different window states.

Portlet Tutorial - Hello Portlet 2.0 World

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series

As explained in the previous post, a portlet is a pluggable component that can be run inside any compliant portal server. Here is an example of a portlet running inside a portal.


Note how the portlet occupies only a part of the portal page. This is the primary difference between a portlet and a servlet. A portlet is meant to occupy only a part of the web page. And a portal web page consists of multiple, different portlets.

Now, let's learn to write a simple Hello World Portlet. The Portlet API defines an interface called javax.portlet.Portlet. Any portlet you write must implement this interface. One easy way to do so is to extend the javax.portlet.GenericPortlet class. The GenericPortlet already implements the Portlet interface and it is strongly recommended that you always inherit GenericPortlet while writing your own portlets.

Here is our code.

public class HelloWorldPortlet extends GenericPortlet{

  public void render(RenderRequest request, RenderResponse response)
                                 throws PortletException, IOException{

    response.setContentType("text/html");
    response.getWriter().write("Hello Portlet 2.0 World");
 }
}

We have overridden only one method of the GenericPortlet interface called render.We will look into the render method in detail in a subsequent blog post. For the time being you can assume that whenever your portlet is "shown" on the portal page, the render method is called.

Since portlets are extended components of a regular web application, they can also be packaged along with your servlets and JSPs in a war file. However you will need a separate descriptor along your regular web.xml to describe portlets. This descriptor is called the portlet descriptor and the file is called portlet.xml.

Here is the portlet.xml for our Hello World Portlet.

<portlet-app xmlns=\"http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd\"
 xsi=\"http://www.w3.org/2001/XMLSchema-instance\" 
 schemalocation=\"http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
 http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd\">
   <portlet>
       <portlet-name>HelloWorldPortlet</portlet-name>
           <portlet-class>com.portalzone.example1.HelloWorldPortlet</portlet-class>
           <supports>
           <mime-type>text/html</mime-type>
           <portlet-mode>view</portlet-mode>
           <portlet-mode>edit</portlet-mode>
           <portlet-mode>help</portlet-mode>
           </supports>
           <portlet-info>
               <title>Hello World Portlet</title>               
           </portlet-info>
       </portlet>
</portlet-app>

That’s it ! You have written your first portlet application. You can grab the ready to deploy war file from here: example1.war and deploy the application to your container of choice. If you are interested in the source, here it is : example1-src.zip.

Portlet Tutorial - Web Portals and Portlets

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series

Introduction to Web Portals

A Web portal is a website that acts as a single point of access for a wide variety of information. Think of a site like Yahoo.On Yahoo, you can check news, shop, read your emails, chat, play games etc. You also have access to a wide varietyof other content and services provided by Yahoo. Yahoo is a good example of a Web portal.

Web portals need not always be accessible to everyone. They can exist within the confines of an organization, accessible to only people who are a part of the organization like employees, contractors, partners, suppliers etc. These portals are called Intranet Portals.Portals like Yahoo, that are open to all, are called Internet Portals.

Web Portal software

While it is possible to build a web portal like any other website using technologies like Servlet/JSP, ASP, PHP etc, today there exists a wide range of software that help build a web portal pretty quickly. For instance, If you are a .Net developer you could consider using the Microsoft Office Sharepoint Server

The advantage of using portal server software is that the software would already have most of the common portal functionality in place. All portal software will offer some means of managing your users (user management), login/logout (authentication), skins/themes (customization), creating multiple user profiles (personalization), search etc. Most portal software will offer significant out-of-the-box functionality like RSS feedreaders and email/calendar applications. Thus portal software, in general, will reduce the amount of code that you need to write to have a portal up and running. It reduces your design/code/test/debug cycles and also makes your portal easier to maintain/upgrade.

The disadvantage of using portal server software is that sometimes it might not be as flexible as you want it to be. All portals offer only a certain degree of customization. If you require something beyond that, you might be better off writing your own solution. Most portals are bulky, loaded with features and functionality. If you are looking for something that's simple, the size and complexity of the portal might come as a pain.

Java Portlets

While all portal software offer many useful out-of-the-box functionality, sometimes it is necessary to write your own custom code and "plug it" into the portal. Java portals allow you to do do this by writing a standardized plugin component called a Portlet. The Java Portlet , defined by the JSR 286, allows you to write your own code and put it into any compliant portal server. Just like you can write a servlet and deploy it to any web server/servlet container , you can write a portlet and deploy it to any portal server/portlet container.

There are a wide array of vendors that support the Portlet spec. IBM, BEA, Sun, Jboss, Liferay, Apache, Exo are a few examples.

Portlet 2.0 (JSR 286) Tutorial

In this ongoing series of blog entries I intend to provide a comprehensive guide to creating web portals using the Java Portlet technology. This tutorial assumes prior knowledge of Java Servlets and Java Server Pages (JSP).

Posts in this series

1. Web Portals and Portlets


2. Hello Portlet 2.0 World




• Deploying your first portlet to OpenPortal Portlet Container 2.0


• Deploying your first portlet to JBoss Portlet Container





3. Anatomy of a Portlet