Introducing the
Portlet Specification, Part 2
Tutorial Details:
Introducing the Portlet Specification, Part 2
Introducing the Portlet Specification, Part 2
By: By Stefan Hepper and Stephan Hesmer
The Portlet API's reference implementation reveals its secrets
nterprise 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:
Part 1: Get your feet wet with the specification's underlying terms and concepts
Part 2: The Portlet API's reference implementation reveals its secrets
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 .
Pluto's architecture
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.
The portal
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 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.
The Portlet Container Invoker API, also called an entrance point, acts as the portlet container's main calling interface. The API combines a portlet container's lifecycle ( init , destroy ) with request-based calling methods ( initPage() , performTitle() , portletService() , and so on). Because the portlet container calls a portlet in the end, the method signature resembles the Portlet API's main portlet interface, except that a portlet identifier must be passed. With this additional portlet identifier, the container can determine the portlet and call it accordingly.
Besides using the APIs to access the portlet container, the portal must implement SPIs defined for the portlet container. Therefore, the RI introduces container services: pluggable components that can be registered at the container to either extend or provide basic functionality. The RI includes the following built-in container services (the first four must be implemented to run the portlet container, while the fifth is optional):
Information provider: Gives the portlet container information about the portal and its framework. Only known information or information that should be stored within the portal is present through this interface. Such information includes URL generation with navigational state, portlet context, portlet mode, and window-state handling.
Factory manager: Defines how to get an implementation through a factory. (A normal portal should already own such an implementation.)
Log service: Defines a logging facility. (A normal portal should already own such an implementation.)
Config service: Defines how to get configuration values. (A normal portal should already own such an implementation.)
Property manager (optional): A property manager interface implementation lets a portal handle properties as defined in the JSR 168 specification.
Strictly speaking, the Portlet Object Model also acts as an SPI, but has an exceptional position among the SPIs. Therefore, don't consider it part of the container services as it deals with all portlet objects and comprises a collection of interwoven interfaces.
Figure 2. The portlet container's architecture. Click on thumbnail to view full-size image.
Portlet deployment
The portlet container can leverage the servlet container's functionality, upon which the portlet container is built. To accomplish that, the portlet container must inject servlet artifacts into each portlet-application war file, as Figure 3 shows. The portlet component, Deployment, takes the original war file, then injects a new or modified web.xml and a servlet to wrap each portlet and uses it as a calling point. Then the portlet deployment passes the modified war file to the application server deployment, which deploys it into the application server's system. During the portlet's invocation, the portlet container calls the injected servlet as an entrance point into the deployed portlet war file.
Figure 3. Portlet deployment in the RI. Click on thumbnail to view full-size image.
Pluto and the WSRP standard
As described in Part 1 , JSR 168 aligns closely with the Web Services for Remote Portlets (WSRP) standard. Both standards, which emerged at the same time, released open source implementations capable of all necessary functions described in the respective specifications. As a mutual goal, both standards strive to work well together. As a result, the portlet container can run WSRP portlets as a consumer as well as a producer.
Pluto must be able to run multiple portlet containers in one portal. Consequently, Pluto's portlet container can be instantiated multiple times and, more importantly, it can be instrumented in different ways. Each portlet container, therefore, can use different implementations for SPIs.
Install the RI
You'll find Pluto's installation process straightforward and easy?simply execute the install command, either install.bat or install.sh , located in the build directory /build . After you start the command, the installation asks for Tomcat's installation directory. (Note: In Microsoft Windows don't use backslashes in the directory.)
After that, the installation process builds the RI and all portlets, then installs the portlets into the designated Tomcat directory. Please read all the important notes printed after the installation to ensure you perform all necessary manual steps.
Now simply start Tomcat and access the RI via http://localhost:8080/pluto/portal . That's all!
How to deploy portlets
Portlet deployment in Pluto is even easier than the installation process. Just remember you must install Pluto first, as that process sets the prepareRun.properties correctly, which the deployment process requires. Simply open a command prompt pointing to the build directory, and then enter the following line in which the parameter defines the portlet war file to be deployed:
deployPortlet.bat C:\pluto\portlets\bookmark_04\driver\bookmark_04.war
Example portlets
Let's look at an example portlet, the Bookmark, to put the Portlet API to its best use and apply the concepts you've learned. Beginning with the first simple example, each section below extends the Bookmark portlet step by step, finishing with an advanced portlet that employs nearly all aspects of the Portlet API.
Bookmark portlet: Version one
The first simple Bookmark portlet employs the following Portlet API features:
The Portlet API interface
JavaServer Pages (JSP) pages
The Portlet API tag libraries
Deployment descriptors
The first example Bookmark portlet's two JSP pages render in the view or edit mode. Each JSP page simply shows the portlet's currently active portlet mode and window state. To display that information, use the Portlet API tag library:
public void doView (RenderRequest request,
RenderResponse response) throws PortletException, IOException
{
response.setContentType("text/html");
String jspName = getPortletConfig().getInitParameter("jspView");
PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher(jspName);
rd.include(request,response);
}
Next, the following code shows a simple JSP page used in the example:
<%@ page session="false" %>
<%@ page import="javax.portlet.*"%>
<%@ page import="java.util.*"%>
<%@ taglib uri='/WEB-INF/tld/portlet.tld' prefix='portlet'%>
Hello,
I am the bookmark portlet.
<
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Introducing the
Portlet Specification, Part 2
View Tutorial: Introducing the
Portlet Specification, Part 2
Related
Tutorials:
 Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
Create forward-compatible beans in EJB,
Part 1 - JavaWorld December
1999
Create forward-compatible beans in EJB,
Part 1 - JavaWorld December
1999
|
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
Program your Palm in Java, Part 1: The PalmOS
Emulator - JavaWorld November
1999
|
Make room for JavaSpaces, Part 4 - JavaWorld April
2000
Make room for JavaSpaces, Part 4 - JavaWorld April
2000
|
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
|
Survival of the fittest Jini services, Part 2 - JavaWorld July 2001
Survival of the fittest Jini services, Part 2 - JavaWorld July 2001
|
Implement Design
by Contract for Java using dynamic proxies
Implement Design
by Contract for Java using dynamic proxies
|
I want my AOP!,
Part 2
I want my AOP!,
Part 2
|
Jini's relevance emerges, Part
2
Jini's relevance emerges, Part
2
|
Develop Java
portlets
Develop Java
portlets
|
Introducing the Portlet Specification, Part 1
Introducing the Get your feet wet with the specification's underlying terms and concepts
|
Introducing the
Portlet Specification, Part 2
Introducing the
Portlet Specification, Part 2
|
JavaServer Faces, redux
JavaServer Faces, redux
|
JDBC scripting, Part 2
JDBC scripting, Part 2
Programming and Java scripting in JudoScript
Summary
JudoScript is a rich functional scripting language, and an easy and powerful general programming and Java scripting language.
JudoScript's power comes from its synergy of
|
The ABCs of Synchronization, Part 1
Threads may execute in a manner where their paths of execution are completely independent of each other. Neither thread depends upon the other for assistance. For example, one thread might execute a print job, while a second thread repaints a window. And
|
Portlet Community
Portlet Community
If J2EE based portals, JSR 168 or WSRP mean anything to you, you have come to the right place.
|
A well-behaved Jetspeed portlet
This article presents a working example of how to construct a Jetspeed portlet that runs efficiently, adheres to the Model 2 architecture, and, by not interfering with additional portlets, plays well with others. In addition, I demonstrate some simple way
|
Java Beans, Part 1 Introducing Java Beans
The basic idea of the Beans tutorial is to get you to the point where you can quickly create beans. You may want to write new beans from scratch, or you may want to take existing components, applets, or other classes and turn them into beans.
|
Unclog the server bottleneck with active containers.
In server-side control architectures such as Java ServerFaces (JSF) or Struts, a majority of the control events must be handled on the server side to update the state of the control. For every user event, the entire page data is sent back to the server...
|
Running JavaServer Faces Technology-Based Portlets on Sun Java System Portal Server 6 2005Q1
You can extend the framework based on JavaServer Faces technology and then run a JSR 168-compliant portlet on Sun Java System Portal Server 6. This article describes the setup procedures, offers sample code, and summarizes the known issues.
|
|
|
|
