Understanding the Portlet Component Model in IBM WebSphere Portal Abstract

Understanding the Portlet Component Model in
IBM WebSphere Portal
Peter Fischer
Stephan Hesmer
Thomas Schaeck
IBM Software Group
July, 2003
© Copyright International Business Machines Corporation 2003. All rights reserved.
Abstract
Initial portal products were traditional, monolithic architectures. Currently, there is a strong drive towards
highly modular architectures based on portal frameworks and interactive Web application components,
authentication, content management, and search plug-ins, from different sources.
IBM WebSphere Portal realizes this modular approach. In particular, it provides a well-defined API
that enables these interactive Web applications, referred to as portlets, to be easily plugged in.
Portlets are special servlets; they can be developed using common J2EE development tools. They are
packaged in standard WAR files that can be deployed while the Portal Server is in use. Because they are
special servlets, portlets can access all functions that are available to servlets, and they can participate in
the run time, management, and system analysis infrastructure of the WebSphere platform.
In contrast to regular servlets, portlets are aware of the WebSphere Portal infrastructure and can exploit
portal specific functions through the Portlet API, which extends the Servlet API.
In this paper, we describe the portlet component model and the Portlet API employed in the IBM
WebSphere Portal for MultiPlatforms V4.2. Finally, we provide an example of a portlet written to this
API.
Table of Contents
1. Overview................................................................................................................................. 2
2. Portlets .................................................................................................................................... 3
2.1.
Portlet invocation ............................................................................................................ 4
2.2.
Implementing portlets ..................................................................................................... 7
2.3.
Displaying portlets on mobile devices............................................................................ 8
2.4.
Portlet development tools ............................................................................................... 9
3. Portlet related concepts ......................................................................................................... 11
3.1.
Portlets, servlets, and J2EE........................................................................................... 11
3.2.
Portlet applications........................................................................................................ 11
3.3.
Portlet templates............................................................................................................ 12
3.4.
Portlet instances ............................................................................................................ 12
3.5.
Portlet life cycle ............................................................................................................ 13
3.6.
Portlet API extensions................................................................................................... 15
3.7.
Portlet tags in JSPs........................................................................................................ 15
3.8.
Brief example................................................................................................................ 17
4. Standardization ..................................................................................................................... 18
5. Conclusion ............................................................................................................................ 18
6. References............................................................................................................................. 18
7. About the authors.................................................................................................................. 19
8. Trademarks ........................................................................................................................... 19
1. Overview
Portals are Web sites that serve as a starting point to information and applications on the Internet or from
an intranet. Portals provide personalized access to information, applications, processes, and people.
Typically, portals get information from local or remote data sources, such as databases, transaction
systems, syndicated content providers, and remote Web sites. They render and aggregate this information
into composite pages to provide information to users in a compact and easily consumable form. In
addition to pure information, many portals also include applications, such as e-mail, calendar, organizers,
banking, bill presentment, host integration, and others..
Different rendering and selection mechanisms are required for different kinds of information or
applications, but all of them rely on the portal’s infrastructure and operate on data or resources owned by
the portal, such as user profile information, persistent storage, or access to managed content.
Consequently, most of today’s portal implementations provide a component model that allows plugging
components referred to as portlets into the portal infrastructure. Typically, portlets are user-facing,
interactive Web application components that run on the portal server, processing input data and rendering
output. Figure 1 shows an example of a portal page, with multiple portlets, generated by WebSphere
Portal.
2
Figure 1. Example of a portal
Each portlet is responsible for providing specific information and must, therefore, perform tasks such as
accessing content from its source (for example, a Web site, database, or email server) and transforming
the content so that it can be rendered to the client most efficiently. IBM WebSphere Portal for
Multiplatforms Version 4.2 (hereafter called WebSphere Portal) provides a framework of services to
make the task of writing and managing portlets as easy as possible.
2. Portlets
From a user's perspective, a portlet is a small window in the portal page, which provides a specific service
or information; for example, a calendar portlet or a news feed portlet. From an application development
perspective, portlets are pluggable modules designed to run inside the portlet container of WebSphere
Portal.
Portlets can use the portal infrastructure to access user profile information, participate in window and
action events, communicate with other portlets, access remote content, look up credentials, and store
persistent data. To make using these tasks easy, the Portlet API provides standard interfaces for these
functions.
The market report portlet example shown in Figure 2 shows a portlet of medium complexity. The market
report portlet has a VIEW mode that displays a list of stock quotes, in this example only for the stock of
the corporation running the employee portal. If users want to add other stock symbols to be tracked, they
would click on the “Edit” button in the title bar displayed by the portal around the portlet. Then the portal
displays the EDIT mode of the portlet.
3
Figure 2. Example of a portlet
To find out how the portlet works, the user clicks the help button, (that is, the ? icon), and the portal
displays the HELP mode of that portlet. To maximize the portlet, the user clicks the maximize button.
Each of the supported modes of a portlet might consist of one or more fragment views. For example, the
VIEW mode in this example consists of fragment views for the stock quotes list and market details.
While Figure 2 shows only the HTML view of the portlet, the same portlet could also have alternative
views which produce different markup to display and read when for users of a WAP phone, a PDA, or a
normal telephone and a voice gateway.
2.1.
Portlet invocation
Typically, portal server implementations include a component which receives requests and aggregates
personalized content for each user, and a component in which portlets run and which provides portlets
with the required context. Figure 3 shows how portlets invoked by a J2EE-based portal.
In the example shown in Figure 4 users click the market details link in the market report portlet. The
user’s browser generates an HTTP request that is received by the portal servlet. The portal servlet
internally invokes code to determine the set of portlets to be displayed for the user, dispatches the request
to the targeted action of the market report portlet, invokes the set of portlets on the page, aggregates their
content into a single HTML page, and returns the page to the user.
4
Figure 3. Invocation of portlets in a J2EE based portal server
A typical portlet consists of a title bar, portlet content, and a border. A typical title bar displays the portlet
title and icons for edit, minimize/restore, maximize/restore, and help. The portlet content is the
information, application, and other data displayed within the portlet. The skin defines the title bar and
border for the portlet. The portal theme and skin files define the look (style) and feel of the portal
elements, such as the portlet title, field labels, icon labels, table headers, table rows, title bar color, icons
and borders.
Portlets typically make use of two modes, a view mode and an edit mode. The view mode is used to
deliver content, display data, present information, and provide the core functionality to users. The edit
mode allows the user to customize or personalize the display mode of the portlet.
Figure 4 shows a world clock portlet that can display the current local time and the time for different parts
of the world.
Figure 4. The World Clock Portlet in the VIEW mode
5
To explain its function to users, the portlet provides a help mode, as shown in Figure 5. Users activate
help by clicking the help icon in the portlet title bar.
Figure 5. The World Clock Portlet in the HELP mode
Among other things, the help mode explains how to customize the portlet using its edit mode. Users reach
the edit mode by clicking the edit icon in the portlet title bar. The edit mode lets users select the cities
around the world for which the world clock portlet will display the current time, as shown in Figure 6.
6
Figure 6. The World Clock portlet in EDIT mode
Portlets are designed to be aggregated into the larger context of composite pages. For example, multiple
instances of the same portlet parameterized with different per-user, per-instance portlet data can coexist
on the same portal page. Usually, many portlets are invoked in the course of handling a single request to
aggregate their respective markup fragments in a portal page. The markup fragments generated by portlets
often need to contain links to trigger actions in the portlet, therefore URL-rewriting methods are required.
These methods enable portlets to transparently create links within the markup fragments they output,
without needing to know how URLs are structured in the particular Web application.
2.2.
Implementing portlets
Internally, portlets can be implemented in different ways. For example, portlets may be implemented
following the Model-View-Controller pattern. The model and controller are Java classes and the views
are Java Server Pages, XSLT style sheets, or other types of templates.
Portlets rely on container infrastructure accessible through the Portlet API, whose functions include:
-
Access to user profile information for the current user
Access to the window object that represents the window in which the portlet displays
Participation in the portal window and action event model
Access to Web client information and inter-portlet messaging
The API also provides a standard way of storing and retrieving persistent per-user/per-instance data.
Portlets can use all the J2EE services that are available to servlets, and vendor-provided connectors to
access back-end data and applications or services in the Internet.
To deploy portlets, you can group them in portlet applications, which are packaged into portlet archive
files containing a deployment descriptor, Java classes, jar files, and resources.
7
All elements in a portlet inherit their look and feel from the style sheet used in the portal. The style sheet
is a part of the theme. Each theme produces a different look and feel inside portlets.
Figure 7 is an example portlet which uses the default theme style sheet . It shows an appealing and
consistent look & feel.
Figure 7. Portlet GUI component examples
2.3.
Displaying portlets on mobile devices
Portlets can be viewed on a number of devices, including desktop computers, PDAs, mobile phones, and
others. An individual portlet can support multiple markups, including HTML, WML, and CHTML. The
interaction models, behavior, look and feel, and technological possibilities vary from device to device,
and from markup to markup. When you design and implement a portlet, consider the intended devices for
the portlet, the tasks that should be available per device, and the interaction model per device.
When you enable or provide portlets for devices, you enable your users to access content and information
through a number of methods, which lets them access your portal any time, from any place, and on any
device.
Because handheld devices have smaller display spaces, challenging data input capabilities, and restricted
network bandwidths, you don’t implement a portlet on a device as a mirror of the entire portlet
implemented for a desktop browser.
Portlets on devices generally provide only the basic or most essential information necessary to complete a
portlet specific task on the device. Tasks should be streamlined for the particular device and each task is
typically a subset of the portlet on a traditional PC. Portlets follow the guidelines, rules and interactions
model inherent to the device.
A portlet on a device still consists of a title, action icons, and the portlet content. However, this
information is rendered differently depending on the specific device, as shown in Figures 8 and 9.
8
Figure 8. A news portlet displayed on a Pocket PC
Figure 9. A Portal displayed on a WAP device
2.4.
Portlet development tools
In today’s fast developing world there is a need to very quickly create applications and bring them to a
production level, with as few errors as possible. WebSphere Portal recognizes this need and provides an
9
environment that fully supports the portlet developer. IBM provides the Portal Toolkit to debug portlets in
a running WebSphere Portal system. The toolkit helps developers create portlet applications in IBM
WebSphere Studio Application Developer (hereafter called Application Developer) in a very easy and
comfortable way, using wizards and a predefined set of ready-to-use portlet applications.
Figure 10 shows a portlet debugging session in Application Developer. In the middle-left view, the
developer sees the breakpoints and the current execution line; in the middle-right side, the current method
in the Java class. The developer can also look at all threads and variable vaues currently available in the
system.
Figure 10. The WebSphere application development environment for portlets
Figure 11 shows that debugging of JSPs and setting break points in the JSP code are supported by the
toolkit.
Figure 11. The WebSphere application development environment for portlet JSPs
10
3. Portlet related concepts
This section introduces key concepts related to portlets, including the relationship of portlets to servlets,
the abstract layer concept of portlet templates, and possible ways to configure portlets. It also shows
some enhanced elements used in portlets, portlet JSP tags, and an example portlet.
3.1.
Portlets, servlets, and J2EE
All portlets are based on the Portlet abstract class, which is the central abstraction of the Portlet API.
This API extends the Servlet API, to enable integration with J2EE application servers and to enable
portlets to leverage existing IBM WebSphere Application Server and J2EE functionality.
Portlets are a special type of servlet, with properties that allow them to easily plug into and run in the
portal server. Portlets have some natural restrictions that servlets do not have. Portlets cannot:
-
Send redirects or errors directly to browsers
Forward requests
Write arbitrary markup to the output stream
Generally, portlets are administered more dynamically than servlets. You apply these types of updates
without having to start and restart the portal server:
-
Installing and removing portlet applications consisting of several portlets, using the portal
administration user interface
Portlet settings. Administrators can change.
The portlet container relies on the J2EE architecture implemented by WebSphere Application Server.
Portlets are packaged in WAR files similar to J2EE Web applications and are deployed like servlets. Also,
like other servlets, portlets are defined to the application server using the Web application deployment
descriptor (Web.xml). This file defines the portlet's class file, the servlet mapping, and read-only
initialization parameters.
In addition to the servlet descriptor, portlets must also provide a portlet deployment descriptor
(portlet.xml) to define the portlet’s capabilities to the portal server. This information includes
configuration parameters specific to a particular portlet or portlet application, and general information that
all portlets provide, such as the type of markup that the portlet supports. The portal server uses this
information to provide services for the portlet. For example, if a portlet registers its support for help and
edit mode in the portlet deployment descriptor, the portal server will render icons to allow the user to
invoke the portlet’s help and edit pages.
3.2.
Portlet applications
Portlet applications provide the means to package a group of related portlets that share the same context.
The context contains all resources; for example, images, property files, and classes. All portlets must be
packaged as part of a portlet application.
Portlet applications provide no code on their own but form a logical group of portlets. Portlets within the
same portlet application share their session and can exchange messages.
WebSphere Portal supports dynamic deployment of portlet applications; that is, you can deploy a portlet
application while the portal server is running, without having to restart it, even in a clustered
environment.
11
The administrator installs a new portlet application using the administration portlet. The administration
portlet receives the WAR file that contains the portlet application and the special portlet.xml
descriptor.
The administrator can also remove an existing portlet application, using the corresponding administration
portlet, without having to restart the server.
To keep the existing configuration, children, and instances of installed portlets and portlet applications, an
administrator can update an existing portlet application using the administration portlet. This can be done
without losing any of the data related to that application, and without having to restart the portal server.
3.3.
Portlet templates
WebSphere Portal provides a dynamically configurable hierarchy of portlets, or portlet templates, which
can be managed by portal administrators. A portlet template is a means through which a user-independent
portlet application can be configured and made ready to use by a portal user. WebSphere Portal supports
portlet templates through the concept of concrete portlets and concrete portlet applications. An
administrator can easily adapt and modify an existing portlet application's behavior by simply creating
new concrete portlets and concrete portlet applications.
After deployment, the portlet application is available in the portal and includes one predefined portlet
template. In general, applications can be adapted to specific run-time environments by modifying their
configuration values. In WebSphere Portal, an administrator can create, modify, and delete concrete
portlets and portlet applications during run time of the server. In addtion, an administrator can clone an
existing concrete portlet and portlet application, which results in a new portlet template with different
configuration values.
An example use of portlet templates follows. An administrator creates two concrete portlet applications,
using the stocks portlet, to be used in Europe and in the US. Each portlet template has a hostname in its
configuration, which is set to a server located in either Europe or in the US, to provide quick response
times for the corresponding region. Then, the administrator sets the stock quote default value as IBM, so
that all employees see this quote when the application starts..
3.4.
Portlet instances
The section above introduced the notion of portlet templates, and WebSphere Portal’s implementation as
concrete portlets. These terms basically describe pre-configured and user-independent portlets, which are
ready to be used. Concrete portlets are shown to the user in the customizer, enabling him or her to put a
portlet on his or her page. By putting concrete portlets on the page, the user creates a portlet instance
associated with the concrete portlet.
The portlet instance is linked with the page, which is owned by a user. Therefore, the user owns all portlet
instances on his/her page, and the user can personalize them.
A group page is a normal page, owned by a user or an administrator, who can allow other users to share it.
If the owner allows others to only view the page, they do not own portlets and they see the portlet
instance of the owner. If the owner allows other to personalize the portlets, they can own portlets.
When a user accesses the shared page, and interacts with the user interface, they can indicate an intentions
to personalize a portlet on a page. A new page, with a new portlet instance of the portlet to be
personalized, is created and owned by the user. This page looks like the original group page, showing all
other group portlet instances, and includes the one, new portlet instance with user-specific data. All other
users see the original, unchanged group page.
Figure 12 shows how a user can select portlets and put them on a page.
12
Figure 12. Configuring pages
After placing the three portlet templates on the page in the customizer, it is displayed as shown in Figure
1
3.5.
Portlet life cycle
The portlet container supports two separate phases for rendering a portal page. The first phase deals with
portlet events; the second phase is responsible for the rendering.
Portlet events can be actions, messages, or window events. In the first phase, all portlet events are
processed sequentially in an event queue. If an action is linked with the request, then the processing is
initiated by it. In the action, more events may be sent to other portlets, which may send events to others.
The corresponding methods of the involved portlets are called before the second phase starts, because the
events can influence the state of the portlets, which can require state-specific markup.
In the second phase the service method for all portlets which are to be displayed is invoked to produce
their markup. To optionally allow a portlet to write output (for example, to the header or footer of an
HTML page), the portlet’s beginPage method is called before, and the endPage method is called after,
the service method itself.
13
Figure 13. Invocation sequence of a portlet
These events are known by the Portlet API:
•
Action: An Action event is sent to the related portlet when an HTTP request, associated with a
PortletAction, is received. PortletActions can be linked to URLs by using the Portlet API. Normally,
PortletActions are linked with HTTP references or buttons in HTML forms, enabling the portlet
programmer to implement different processing paths for different user selections. The ActionEvent of
the clicked link carries the associated PortletAction back to the portlet, which processes different
paths on behalf of the PortletAction.
•
Message: Message events can be sent from one portlet to other portlets if the recipient portlets are
members of the same portlet application, and they are placed on the same page as the sending portlet.
MessageEvents can only be sent actively to other portlets when the portlet is in the event processing
cycle of the portlet container; otherwise, an exception is thrown. A DefaultPortletMessage can cross
portlet application boundaries and may be sent to all portlets on a page.
•
WindowEvent: A WindowEvent is sent by the portlet container whenever a user clicks on one of the
control buttons that change the window’s state; for example, the maximize, minimize, or restore.
During the rendering of a portal’s page, all portlets’ service methods are invoked. A portlet normally
supports different tasks, called portlet modes, which let a portlet display a different user interface,
depending on the task. The following modes are provided by the Portlet API:
•
View: When a portlet is initially constructed on the portal page for a user, it is displayed in its view
mode. This is the portlet’s normal mode of operation.
•
Help: If a portlet supports this mode, it provides a help page for users to obtain more information
about the portlet.
•
Edit: If a portlet supports this mode, it provides a page for users to customize the portlet. For
example, a portlet can provide a page for users to specify their location for obtaining local weather
and events.
14
•
Configure: If this mode is supported by a portlet, the portlet provides a page for portal administrators
to configure a portlet for a user or group of users.
To achieve minimal response times and to reduce computational effort, WebSphere Portal 4.2 provides a
portlet level markup cache and parallel portlet rendering, both of which can be configured per portlet.
This is important as the expiry of the cache depends strongly on the content provided by the portlet.
Parallel invocation of portlets only makes sense for portlets with a delay, which does not require
processing power.
3.6.
Portlet API extensions
Portlet services are discoverable extensions to the Portlet API which can be plugged into the portal server.
A portlet can query the container for a specific service type and receive, in return, an implementation of
the corresponding interface, if it is available. Therefore, specific portlet tasks can be encapsulated as
portlet services and used by several portlets. The implementation of such a service can be exchanged and
enhanced transparently to the portlet.
To enable portlets to use pluggable services through dynamic discovery, the Portlet API provides the
PortletService interface. A PortletService is accessed from the PortletContext.getService()
method, which looks up the appropriate factory for the service, creates the service, and returns it to the
portlet.
For example, consider a Credential Vault, which enables portlets to access credentials for authentication.
The CredentialVaultService.class would be available on the portal server but does not belong to
the portlet application (that is, it is not packaged with the portlet’s WAR file).
That service can be retrieved as follows:
import org.apache.jetspeed.portlet.service.PortletService;
import com.ibm.wps.portletservice.credentialvault.CredentialVaultService;
…
CredentialVaultService vault = (CredentialVaultService)
portletContext.getService(CredentialVaultService.class);
Iterator slots = vault.getAccessibleSlots(portletRequest)
Figure 14: Portlet using a portlet service
Various services may be implemented by different vendors; for example, SearchService,
LocationService, ContentAccessService, or MailService. The Portlet API provides a
ContentAccessService.
3.7.
Portlet tags in JSPs
It is good practice to use JSPs to render a portlet’s content. This practice almost ensures you are using the
Model-View-Controller pattern with the portlet’s data as the Model, the portlet code as the Controller,
and the JSPs as the View.
WebSphere Portal provides portlet tags for use in JSPs enabling portlet developers to easily create portlet
JSPs:
Tag
Description
15
if
Several conditions can be checked using the attributes of this tag. If the
condition is true, the content of the tag is written to the page. Otherwise, the
content is skipped. More than one condition can be evaluated. All conditions
must evaluate to be true for the tag contents to be written. Also, each parameter
can contain multiple values separated by commas or semicolons. Only one
value in the list needs to be true for the condition to evaluate as true.
log
Writes a string in the portlet log.
text
Writes a localized string to the output stream. When no resource bundle can be
found, the content between the start and end tag is written to the output stream.
dataLoop
Loops through all attributes in PortletData of the current concrete portlet
instance. Use the dataAttribute tag to get the attributes between the dataLoop
start and end tag.
dataAttribute
Returns the value of one or more PortletData attributes. The attribute can be
specified by the name parameter. You can also use this tag within a dataLoop
tag to retrieve all attributes or a subset of the attributes from PortletData.
settingsLoop
Loops through all attributes in PortletSettings of the current concrete portlet.
Use the settingsAttribute tag to get the attributes between start and end tag.
settingsAttribute
Returns the value of one or more PortletSettings attributes. The attribute can be
specified by the name parameter. You can also use this tag within a
settingsLoop tag to retrieve all attributes or a subset of the attributes from
PortletSettings.
CreateReturnURI
Creates a URI that points to the caller of the portlet. You can pass a parameter
or action in the URI by including URIParameter or URIAction between the
CreateReturnURI start and end tags.
createURI
Creates a URI that points to the current portlet with the given parameters. You
can pass a parameter or action in the URI by including URIParameter or
URIAction between the createURI start and end tags.
URIParameter
Adds a parameter to the URI of the createURI and CreateReturnURI tags.
URIAction
Adds a default action to the URI of the createURI and createReturnURI tags.
The portlet must have a registered action listener to handle the event.
EncodeNamespace
Maps the given string value into this portlet's namespace. Use this tag for
named elements in portlet output (for example, form fields or Javascript
variables) to uniquely associate the element with this concrete portlet instance
and avoid name clashes with other elements on the portal page or with other
portlets on the page.
init
Provides the following variables which the JSP can use to access the
corresponding objects of the portlet API:
portletRequest
16
portletResponse
portletConfig
3.8.
Brief example
The following example shows the View mode of a stock quote portlet with a JSP using a user tag to
display the portfolio owner name and portlet data to store stocks of interest.
package com.mycompany.portlets.stocks;
…
public class StocksPortlet extends PortletAdapter implements ActionListener {
…
public void doView (PortletRequest request,
PortletResponse response)
throws PortletException, IOException
{
StocksBean bean = new StocksBean();
boolean show = request.getParameter(STOCKS_DETAIL) != null;
bean.setShowDescription(show);
PortletURI uri = response.createURI();
if (show) {
bean.setMessage("Hide Description");
} else {
bean.setMessage("Show Description");
uri.addParameter(STOCKS_DETAIL, "true");
}
bean.setUrl(uri.toString());
request.setAttribute("stocksBean", bean);
getPortletConfig().getContext().include("/WEB-INF/jsp/view.jsp", request, response);
}
…
}
Figure 15: Stock portlet source, StocksPortlet.java
<%@ page session="false" %>
<%@ taglib uri="/WEB-INF/tld/portlet.tld" prefix="portletAPI" %>
…
<jsp:useBean id="stocksBean" class="com.mycompany.portlets.stocks.StocksBean" scope="request" />
<portletAPI:init/>
<TABLE class="Portlet" width="100%" border="0" cellspacing="0" cellpadding="0">
<TR><TD>
<b>Stock Values:</b>
</TD></TR>
<%
Enumeration stocks = portletRequest.getData().getAttributeNames();
while (stocks.hasMoreElements())
{
String symbol = (String) stocks.nextElement(); %>
<TR><TD>
<FONT COLOR=blue><%=symbol%> </FONT>
</TD>
<% if (stocksBean.isShowDescription())
{ %>
<TD> <%=portletRequest.getData().getAttribute(symbol)%> </TD>
<% } %>
<TD> <%=Math.round(Math.random() * 1000)%>.00 $ </TD>
</TR>
<% } %>
17
<TR><TD>
<BR> <A HREF='<%=stocksBean.getUrl()%>'><%=stocksBean.getMessage()%></A>
</TD></TR>
</TABLE>
Figure 16: Stock portlet view.jsp
4. Standardization
With the emergence of an increasing number of enterprise portals, a variety of different APIs for portlets
has been created by different vendors. The variety of incompatible interfaces creates problems for
application providers, portal customers, and portal server vendors. To overcome these problems, the Java
Portlet API standard will provide interoperability between portlets and portals.
With this standard in place application providers or portal customers can write portlets independent from
specific enterprise portal products. IBM initiated the Java Portlet API and WSRP (Web Services for
Remote Portlets) standards, and is committed to implementing these standards in WebSphere Portal as
soon as they are completed. The WebSphere Portal 4.2 release already provides an API for locally
deployed portlets written in Java and a Web services interface for remote portlets that are architecturally
consistent with the emerging standards.
5. Conclusion
The portlet concept in WebSphere Portal provides a well-defined programming model for pluggable
portal components that is supported by the portal runtime, and by WebSphere tools. It helps integrate
applications, content, Web services, and data through portlets written to the Portlet API. IBM and its
partners have made available a large number of portlets for WebSphere Portal in the WebSphere Portal
Catalog at http://www.ibm.com/websphere/portal/portlet/catalog.
In addition to running portlets locally, WebSphere Portal enables administrators to publish selected
portlets as remote portlet Web services for use by other portals. Furthermore, it lets administrators
integrate remote portlet Web services published by other portals through the administrative user interface,
without any programming effort, see [4].
6. References
[1] IBM WebSphere Portal product page
http://www.ibm.com/websphere/portal
[2] Portlet Developer’s Guide, Second Edition
http://www7b.boulder.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/V42PortletDevelopmentGuide.pdf
[3] WebSphere Portal Zone
http://www.ibm.com/websphere/developer/zones/portal/
[4] Easily integrating remote portlet Web services with your portal
ftp://ftp.software.ibm.com/software/websphere/pdf/WSPortl_WebSrvcs_G32520980.pdf
[5] Portlet API JSR 168
http://jcp.org/aboutJava/communityprocess/review/jsr168
[6] Setting up a Portlet Development Environment Using WebSphere Studio V5.0.1 and Portal Toolkit
http://www.ibm.com/websphere/developer/library/techarticles/0308_yang/yang.html
[7] WebSphere Portal Catalog
http://www.ibm.com/websphere/portal/portlet/catalog/
18
[8] Develop portlets that use Web services to obtain data from remote systems
http://www-106.ibm.com/developerworks/ibm/library/i-wsadportlets/
7. About the authors
After finishing his studies at the top of the class at Staatliche Studienakademie Sachsen in
Dresden, Germany in 1999, Peter Fischer has been working as a Software Engineer for
IBM in the development lab in Boeblingen, Germany. He is currently working in
WebSphere Portal Development as the technical team lead of the Web Services/Web
Services for Remote Portlets (WSRP) team. He is responsible for the architecture and design
of the WSRP implementation in WebSphere Portal Version 5 and the Apache Charon
project. In his spare time, Peter likes to spend time with his girlfriend, go mountain biking,
or work on one of his vintage cars. You can contact Peter at [email protected].
Stephan Hesmer received a Diploma of Information Technology from the University of
Cooperative Education Stuttgart, in 2000. After graduating, he joined the IBM Boeblingen
Development Laboratory to work in the WebSphere Portal Team. Currently he is the
architect and team lead of the Portlet Environment in the WebSphere Portal and of the JSR
168 Reference Implemention. Stephan has worked with C++ and Java for many years.
Outside work he enjoys hiking, squash, skiing and a lot of other outdoor activites.
Thomas Schaeck is the lead architect for WebSphere Portal Server, the platform for the
WebSphere Portal and Workplace family of products which, among other functions,
includes the portlet runtime and soon WSRP (Web Services for Remote Portlets) support.
He initiated the Java Portlet API (JSR 168) and OASIS Web Services for Remote Portlets
(WSRP) standards and chaired the OASIS WSRP TC in the first year, leading it to the
definition of the WSRP 1.0 standard. Thomas coauthored two books, published various
papers, and numerous patents. Outside work, Thomas enjoys playing tennis, biking and
other sports.
8. Trademarks
DB2, IBM, and WebSphere are trademarks or registered trademarks of IBM Corporation in the United
States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
IBM copyright and trademark information: http://www.ibm.com/legal/copytrade.phtml
19