Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Enterprise portal vendors use pluggable user-interface components, known as portlets, to provide a presentation layer to information systems. Unfortunately, in the past each vendor defined its own portlet API, producing incompatibilities across the industry. To standardize the process, the Java community launched Java Specification Request (JSR) 168: the Portlet Specification.
Part 1 of this two-part series examined JSR 168 in detail. This final article focuses on the Portlet API's reference implementation (RI), also known as Pluto. The RI provides a working example portlet from which you can launch your own development efforts.
Read the whole series on the Portlet Specification:
This article's first section describes the RI's architecture, including the portlet container's plug-in concept and how to reuse the container in other projects. The second section explains how to install and use the RI, as well as how to quickly deploy portlets. The article concludes with a series of progressively more complex portlet examples.
Note: You can download this article's source code from Resources.
Let's begin by examining Pluto's architecture and underlying concepts. First, we briefly explain the portal that runs the RI, and see where to find a portlet container inside a portal architecture. Next, we investigate Pluto's architecture in detail. Last, we look at how it solves one challenging item of the portlet container: portlet deployment.
Pluto normally serves to show how the Portlet API works and offers developers a working example platform from which they can test their portlets. However, it's cumbersome to execute and test the portlet container without a driver, in this case, the portal. Pluto's simple portal component is built only on the portlet container's and the JSR 168's requirements. (In contrast, the more sophisticated, open source Apache Jetspeed project concentrates on the portal itself rather than the portlet container, and considers requirements from other groups.)
Figure 1 depicts the portal's basic architecture. The portal Web application processes the client request, retrieves the portlets on the user's current page, and then calls the portlet container to retrieve each portlet's content. The portal accesses the portlet container with the Portlet Container Invoker API, representing the portlet container's main interface supporting request-based methods to call portlets from a portal's viewpoint. The container's user must implement the portlet container's Container Provider SPI (Service Provider Interface) callback interface to get portal-related information. Finally, the portlet container calls all portlets via the Portlet API.
Figure 1. The simple portal included with Pluto. Click on thumbnail to view full-size image.
The portlet container, the portlets' runtime environment and a core component of each portal, requires knowledge about the portal itself and must reuse common code from it. Consequently, the portlet container remains completely separated from every other portal component. That said, you can embed the standalone portlet container in any portal by complying with the portlet container's requirements, such as implementing all SPIs.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Pluto.... sounds really basic By Anonymous|
|PLUTO released in CVS By Anonymous|
|Problems deploying bookmark1 example on Pluto By Anonymous|
|evaluate-while-typing By Anonymous|
|Reference Implementation? By Anonymous|
|Error messages while trying to deploy war-File... By Anonymous|
|User-Attributes By Damian|
|reg: IFramePortlet By Anonymous|
|How useless! How to install what you can't get??? By Anonymous|
|regarding link in portlet By Anonymous|
|How to access the portlet once deployed? By Anonymous|
|Mars may be close but where is Pluto? By Craig|
|deployPortlet.bat ? where is it? By ArijkA|