From the IBM WebSphere Developer Technical Journal.
The first version of the Java Portlet Specification, developed as JSR 168 and finished in 2003, is now widely supported in the industry and by open source. First versions of a standard or product typically have the drawback of supporting just the most basic use cases with limited functionality. This was also true of the Java Portlet Specification V1.0, and so, three years later, most portal products supporting the Java Portlet Specification V1.0 provide add-on extensions to support more advanced use cases. Thus, the Java Portlet Specification V2.0 was started as JSR 286 in November 2005 to catch up with the industry and provide a standard solution that would accommodate most advanced use cases, thereby bringing interoperability back for these advanced features. Even though this new specification is not finalized, it could be worth your while to get familiar with it now.
Why look at an early draft of a specification?
The first early draft of JSR 286 was released this August by the JSR 286 Expert Group, covering the features most often requested. A second early public draft covering all features will be released near the end of the year. So if this isn’t the final version of the specification, why should you take a look at the early drafts of JSR 286?
To provide feedback.
Receiving feedback on early drafts give the expert group a chance to really evaluate and change things in the specification. Most features are frequently not completely implemented and tested in an early draft, and so changes are easier to accommodate than in later review cycles, where the decision often comes down to either delay the schedule of the specification or to remove the feature from this version entirely. Early public drafts, therefore, enable a broader community to influence a JSR than just the expert group that is putting it together. This is important, since an expert group made up of 30 or more people can make the specification process very slow.
I think that a relatively small expert group (made up of 20 to 30 people with different areas of expertise) plus several early public drafts (that introduce new features, even if they are not completely baked) will provide a better standard faster than if everyone who was interested in a JSR was accepted as member of the expert group.
Here, then, is your chance to provide feedback on the first early draft of the Java Portlet Specification.
The first draft of the Java Portlet Specification V2.0 covers the most often requested features that were not in V1.0, such as coordination between portlets, serving resources, portlet filters, or AJAX support. Like V1.0, V2.0 will also be based on J2EE 1.4 and thus will let portlets use J2EE 1.4 enhancements, such as JSP 2.0. Following are some of the major features of this new specification.
A major objective with this version of the specification is the alignment with WSRP 2.0, which is also currently under development. The goal, as with the Java Portlet Specification 1.0 and WSRP 1.0, is the ability to publish remote Java portlets and create proxy Java portlets that can proxy WSRP remote portlets into J2EE portals; for example, your portlet will be able to send and receive events to and from local running portlets, even if your portlet is running remotely.
JSR 286 introduces three different coordination concepts to make it easier to create composite applications using portlets from different portlet applications:
-
Events -- for sending and receiving events.
The event model that JSR 286 defines is a loosely-coupled, brokered event model. In this model, the portlet defines the events it can receive and the ones that it may publish in the portlet deployment descriptor. At run time, the portal administrator (or business users) can wire together the different portlets.
-
Shared render parameters -- for sharing render parameters between portlets and thus creating a page context.
Shared render parameters are declared in the portlet.xml file. The portlet will automatically receive these parameters if they are not null. In contrast to non-shared render parameters, the portlet only needs to set shared render parameters if the value should change. From the API point of view, shared render parameters are treated like normal render parameters, and thus can be accessed with the render parameter methods.
-
Shared session attributes -- for sharing session data beyond the current Web application.
JSR 286 provides the shared session attributes that can be shared across Web applications. In the portlet.xml file, you can define the attributes that are shareable declaratively, and then use the existing portlet session APIs and the application session scope to share this attribute across Web applications.
In JSR 168, the only way for portlets to serve resources is either through direct links to the resource, or by serving the resource through a servlet. While direct links are very efficient for static resources that are the same for all portlet states, they are insufficient for other use cases where you would like to take information from the portlet context into account. Examples for this include rendering different resources based on the portlet mode, window state, current render parameters, or portlet preferences.
Another benefit of rendering resources directly through the portlet is that, in this case, the resource is accessed through the portal, and thus protected through the portal access control. Of course, this comes with the cost of an additional portal request that puts more load on the portal server.
To support the resource rendering use case through the portlet, JSR 286 introduces a new optional lifecycle interface called ResourceServingPortlet, with the method serveResource, that can be triggered by a ResourceURL, which the portlet can create via the PortletResponse.createResourceURL method. A resource URL contains the current transient state of the portlet (portlet mode, window state, render parameters), but cannot set new values for this state. A resource URL may have additional resource parameters that are set on the resource URL.
The resource serving lifecycle interface also enables rendering markup fragments asynchronously without coordination with the portal by using the standard XMLHttpRequest, and thus supports some of the basic AJAX use cases for portlets. The portlet can leverage all the information in the portlet context, like portlet mode, window state, render parameters, or portlet preferences. The limitations are that you cannot change any of the previously mentioned state in such a call.
Portlet windows are only indirectly reflected in the first version of the Java Portlet Specification, as part of the prefix that the container generates for portlet-scoped session entries. V2.0 of the specification now makes this portlet window ID available to the portlet via the request, and, thus, the portlet can use this ID to key data that it would like to store.
A common use case that this enables is caching of data in the portlet; for example, data retrieved from slow backend systems, and that is different for various portlet windows. With the portlet window ID, the portlet now has the means to cache such data in cache systems provided by the application server, or by another caching system.
Portlet filters can be put in front of any lifecycle method call available in the V2.0 specification (processAction, processEvent, render, serveResource), and also enables these lifecycle methods to have a wrapped request and response. Similar to servlet filters, portlet filters need to be defined in the portlet.xml deployment descriptor.
Even if you are unable to review the first early draft and provide feedback before the review period closes, be sure to watch for the release of the second early draft. For the second early draft review, additional features under consideration include: further AJAX support, validation-based caching, request dispatcher include calls from all lifecycle methods, and more.
Providing feedback on what you would like to see in V2.0, in addition to the current features, will help the expert group put the features into the specification that will be most useful to you. We look forward to your feedback!
Stefan Hepper is the responsible architect for the WebSphere Portal and Workplace programming model and public APIs. He co-led the Java Portlet Specification V1.0 (JSR 168) and is now leading the V2.0 (JSR 286) effort. Stefan received a Diploma of Computer Science from the University of Karlsruhe, Germany, and in 1998 he joined the IBM Böblingen Development Laboratory.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
