1. Harnessing JSR-168
Harnessing JSR 168
Assets, Portlets, & the Portlet Container
Presented by Andrew Wills
Unicon Academus Technical Lead
awills@unicon.net
2. Harnessing JSR-168
Portlets, uPortal, & Academus
October 2003
Final Release, v. 1.0 of the Portlet Specification
April 2004
uPortal v. 2.3 includes support for portlets
Fall of 2004
Unicon develops Academus v. 1.5, featuring a
completely new Briefcase Portlet
3. Harnessing JSR-168
Scope
This presentation takes a look at creating
a compelling portal based on the
technology defined in the Portlet
Specification v. 1.0
It examines life in the portlet container,
then outlines patterns and practices
geared toward flexibility, inter-
operability, and success
6. Harnessing JSR-168
Portal, Portlet, & Portlet Container
“A portal is a web based application that –
commonly – provides personalization, single
sign on, [&] content aggregation […]” [PLT.2.1]
“A portlet is a Java technology based web
component, managed by a portlet container
[…]” [PLT.2.2]
“A portlet container runs portlets and provides
them with the required runtime environment.”
[PLT.2.3]
7. Harnessing JSR-168
Significant Types
These interfaces shape your role in the
container and resources available from
the container
– Portlet
– PortletConfig
– PortletContext
– PortalContext
9. Harnessing JSR-168
Portlet Interface Methods
Portlet interface methods are of two
kinds:
Lifecycle Management
– init()
– destroy()
Request Processing
– processAction()
– render()
10. Harnessing JSR-168
Lifecycle Management: Initialization
Use the init() method to establish
connections to backend services, read
initialization files, etc
Don’t perform these tasks in constructors
or static initialization blocks. The portlet
is not guaranteed to be in a valid portlet
runtime until the init() method is called
[PLT.5.2.2.2]
11. Harnessing JSR-168
PortletConfig at a Glance
“The configuration holds information
about the portlet that is valid for all
users.” [api PortletConfig]
• One per portlet definition
• Portlet init parameters
• Title & keywords (ResourceBundle)
• Access to the PortletContext
12. Harnessing JSR-168
PortletConfig Example
We used an init parameter from the
PortletConfig to pass the location of a
configuration file to the portlet
String settings =
config.getInitParameter(SETTINGS_PATH);
This approach allowed us to define our
portlet multiple times, each with a
different configuration file
13. Harnessing JSR-168
PortletContext at a Glance
“The PortletContext interface defines a
portlet’s view of the portlet application
within which the portlet is running.”
[PLT.10.0]
• One instance per portlet app.
• Context Init Parameters
• Context Attributes
• Access to Resources (Files)
• Request Dispatching
14. Harnessing JSR-168
PortletContext & ServetContext
“Context attributes set using the
PortletContext must be stored in the
ServletContext of the portlet
application.” [PLT.10.3]
Use context attributes to share
information between your portlets and
servlets/JSPs in the same web
application
15. Harnessing JSR-168
PortletContext Example
We used the PortletContext to access
resources included with our portlet
application
String path = context.getRealPath(settings);
It allowed us, for example, to learn the
full, file system path of the configuration
file indicated by the PortletConfig
16. Harnessing JSR-168
PortalContext at a Glance
“The PortalContext interface provides
information about the portal that is
invoking the portlet.” [PLT.13]
• Vendor and version information
• Portal properties
• Portlet modes & window states
supported by the portal
• Available only within rendering cycles
17. Harnessing JSR-168
Request Processing
Request processing comes in two forms:
– Action Requests
– Render Requests
To develop useful and interesting portlets,
It is essential to understand the
difference
18. Harnessing JSR-168
Request Processing
• Each client request invokes at most one
action request
• Each client request may invoke any
number of render requests, depending
on layout, caching, and other factors
• A portlet may be rendered many times
between action requests
19. Harnessing JSR-168
Request Processing: The Old Way
Browsers operate on the document model
Behavior & web
applications have
been ‘piggybacked’
or retrofitted to the
web
20. Harnessing JSR-168
Request Processing: The New Way
The portlet contract does us a huge favor
by making the distinction more formal
Unlike servlets,
portlets are not
bound to a logical
location (URL) [PLT.3]
21. Harnessing JSR-168
Action vs. Rendering
Keep a sharp distinction between action-
related activities and render-related
activities
Avoid invoking domain behavior in
rendering cycles; avoid UI-bound reads
in the action cycle
22. Harnessing JSR-168
Action Requests
Do:
– Invoke domain behavior
– Change member data in domain (business)
classes
– Change portlet mode, window state, and
portlet preferences
Don’t:
– Process rendering logic (e.g. paging)
– Read data for display
23. Harnessing JSR-168
Render Requests
Do:
– Process rendering logic (e.g. paging)
– Read data for display
Don’t:
– Invoke domain behavior
– Change member data in model (business)
classes
– Change portlet mode, window state, and
portlet preferences
24. Harnessing JSR-168
The Portlet Container
Noteworthy:
• One portlet instance per portlet
definition per JVM
• Zero-argument constructor for portlets
• Request & response objects may be
reused – behavior of references
maintained across cycles is non-
deterministic
25. Harnessing JSR-168
Summary: The Good News
The Portlet Specification improves our
lives as portal developers
– It makes our applications portable, allowing
us to work with competing containers &
enabling us to package our technology as
plugable components
– It gives us a better, more evolved paradigm
for web applications
26. Harnessing JSR-168
Summary: The Other Good News
The Portlet Specification is tightly scoped.
It’s silent concerning topics like
– Rendering technologies & frameworks
– Data access APIs
– Transactional (atomic) operations
– Communication between portlets, portlet
apps, and other systems
27. Harnessing JSR-168
The Other Good News (cont.)
This approach gives portlet developers
the flexibility to choose ‘best of breed’
solutions, or those that are appropriate
to the circumstances
In the context of a portal, these issues
deserve special emphasis; don’t let
‘content aggregation’ begin and end
with the browser window
29. Harnessing JSR-168
What is an Asset?
An asset is a collection of related data
points that represent a single logical
entity
Assets are the work-product that result
from the actions of users upon your
system
30. Harnessing JSR-168
Asset Examples
The following are all assets:
– Files (images, documents, &c.)
– Calendar Entries
– Contacts (e.g. Addressbook)
– News Items & Announcements
– Email Messages
– Learning Objects (e.g. Content, Tests,
Class Rosters)
– Objects from 3rd Party Systems (SIS, CMS,
&c.)
31. Harnessing JSR-168
What is Asset Pervasiveness?
Entities are created, managed,
referenced, and consumed across tool
(portlet) boundaries
32. Harnessing JSR-168
Importance of Asset Pervasiveness
A useful portal aggregates tools to work
together, not simply appear together
Our experience is that application
software doesn’t get adopted in discreet
units. It should be bundled, inter-
operative, inter-compatible, or all of the
above
33. Harnessing JSR-168
Scenario Examples
The following are scenarios involving
asset pervasiveness:
– Send an email to someone in your contacts
list.
– Post an image from your briefcase to a
discussion forum.
– Reference (and link) a calendar entry
within an announcement.
– Share a folder in your briefcase with all the
students in your class.
35. Harnessing JSR-168
Strategies
In the process of developing of
Academus 1.5, we used the following
patterns & practices to make the most
of our assets
36. Harnessing JSR-168
Focus on Assets
Create useful, meaningful entities that are
not tool-bound
Maintain an asset-centric view of your
technology
37. Harnessing JSR-168
Assets Before Tools
Design asset behavior and structures first
38. Harnessing JSR-168
Design Dependencies Carefully
Import asset types from UI types, never
the other way around
39. Harnessing JSR-168
Keep it Clean
Avoid cross-tool imports (portlet-to-
portlet)
Avoid hybrid structures (part model, part
UI). For example, don’t include text-
formatting utility methods on your
entities
40. Harnessing JSR-168
Design Patterns
The following patterns come in handy for
designing asset-based subsystems:
• Abstract Factory
Asset subsystems may have multiple implementations. Use abstract factories to
create entities that play well together
• Adaptor
Use the adaptor pattern to make open source or 3rd party features appear like your
asset subsystems to your portlets
• Façade
Aggregate the services of a complex subsystem into a single point of contact for
your portlets
41. Harnessing JSR-168
Singleton Pattern
Be careful using the Singleton pattern
In most circumstances, asset subsystems
don’t benefit from one-per-JVM
restriction
Asset pervasiveness thrives on flexibility
42. Harnessing JSR-168
Scalability
Design your assets for multi-server
deployments
– Query entities each
rendering cycle
– Plan subsystem
boundaries carefully to
for future
implementations based
on technologies like JMS
& Web Services
43. Harnessing JSR-168
Assets in Portlets
• All users share the same portlet
instance – provide a mechanism to
access the appropriate assets by user
or user session
• Invoke behavior in asset subsystems
only in the action request cycle
• Refresh collections of assets during
each request cycle – action or
rendering
• When displaying asset information, read
the actual asset in each rendering cycle
