WSRP v3 Use Cases
Use case list
1. Theme: Portlets as UI services
2. Functional needs
a.
b.
c.
d.
e.
Content extension points
Consumer resources (e.g. referencable buttons, browser framework, etc)
Popup windows
Generating URLs to other portlets
Extendable render URLs
3. Infrastructure needs/alignment
a.
b.
c.
d.
e.
Leverage WSRF – Portlets as resources
Improved property support – make properties more useful
Expose composed applications rather than just portlets [multiple pagelets with
navigation] – Richard
Expose aggregates as a Portlet – v1 supports non-portal like aggregates
Leverage WSN – Async notifications (e.g. MetadataChanged, CacheUpdate)
4. Reuse CacheControl relative to Templates, UserContexts, etc.?
a.
Unify concepts or have distinct Consumer-cached and Producer-cached models?
Portlets as a UI service
 Most modern applications use component technologies for
view generation

Web domain => linked set of JSPs, ASPs, perl scripts, etc
– Each invocation produces a “page”, though reuse of
control/fragment generation is encouraged.
 Portal concept added a “portlet” granularity; below “page”
level, but above “control” level.
 WSRP added the ability to produce/consume distributed
portlet components.
WSRP -> distributed Portlets
 v1: handle generation and interactions with markup in a
manner agnostic to:





Platform
Transport (though http is explicitly considered)
Mime type (though html is explicitly considered)
Stateful/stateless choices
etc
 Note: v1 included other features as well
WSRP -> distributed Portlets
 v2: Maintain agnostic characteristics of v1 while adding
coordination:

Portlet source of coordination signal/info (events)
 Consumer managed extension of the Portlet’s navState (public
parameters)
 Note: v2 included other features as well
v3 Question
 What is needed to fill out the distributed UI model?

Exposure of Consumer functionality to portlets
 Fuller integration into “page”
 Programmatic access to configuring / customizing portlets
 Larger set of UI techniques available to portlet developers
 Connections to asynchronous models
 …
Portlets as a UI service
Functional needs
1. Content extension points
2. Consumer resources
• Referencable buttons, browser framework, etc
• Available services (e.g. content management system)
3. Popup windows
4. Generating URLs to other portlets
5. Appending query args to render URLs
• Extension of method=get issues/solution?
Content extension points
 Many apps (e.g. Media Player, FireFox) provide facilities for
extensions that can:

Add content in multiple places
– Toolbars
– Menu items
– “Body”
 Add functionality by leveraging
– Notifications
– Plug points in the processing model
 WSRP v1 & v2 only provide for adding content to the “body”
Content extension points – example
Context-sensitive menus in OLE
Select
spreadsheet
object
Content extension points – Portlet defined as well?
 Consider a portlet offering maps.google type markup

Useful to define extension points for other components to overlay onto the
map.

Example: http://www.mackers.com/projects/dartmaps/
Content extension points – example
Portlet defined as well?
Consumer resources
 Previously raised use cases:




Form control layout
Reusable buttons, etc
Access to Consumer managed controls (menus, tabs, etc)
Help system
 General issues:

Providing remote portlet with access to local resources & services.
Examples include:
– After portlet markup incorporates a document list, etc, allow
Portlet controlled URLs to fetch, edit and post new/updated
documents to a Consumer managed document repository.
– Portlets share a common (Consumer-managed) document
repository, but a portlet wishes to validate a document prior to
storing it within the repository.
Pop-ups
 User Interfaces often want to pop-up additional
information



Help/print views on themselves
View a document from a list
Views on other portlets which provide a means to impact the
source portlet
– Example: Mail portlet pops-up an AddressBook portlet
Help/Print pop-up
Pop-up document from List
Pop-up another portlet
Pop-up Portlet impacting source
URLs to other portlets
 The mail/address book scenario needs a portlet url to direct
interaction with a different portlet

Need to be careful the solution doesn’t expand the scope of WSRP to
include communication within the browser!
 Dividing a standard email application into three portlets
(folders, summary and detail) also needs one portlet to
direct interactions with another portlet.
 For example; customers have requested the ability to
replace the content from an email portlet on a page with the
content from a calendaring portlet based either on URL
parameters or the response from action processing.
 Note: recent redirectURL discussion have also raised the
use case of a portlet redirecting to a different Consumer
“page”.
Extendable Render URLs

Consider a document manager portlet:


Top level generates a list of documents as URLs for accessing the document:
1. Each URL can directly reference (i.e. using a render url) an individual
document (doable today)
•
Performance suffers as large numbers of URLs are generated.
2. Each URL can reference a script function passing the documentID.
•
Single URL embedded within the script. Script appends
“documentID=“+documentID
•
Doable if an action url is used, but this doubles the network latency
impact!
Very similar to the issues discussed surrounding forms with
method=get

[Can this be solved via NavigationalParameters or Transient Properties (with
scope=wsrp:consumerRequest)?]
Portlets as a UI service
Infrastructure needs/alignment
1. Leverage WSRF – Portlets as resources
2. Improved Property support – make properties more useful
3. Composite applications – rather than just portlets
4. Expose aggregates as a portlet – some use cases supported now
5. Leverage WSN – Async notifications (MetadataChanged), etc
Leverage WSRF
 As WSRF emerges as the standard for managing
interactions with web service based resources, it is
time to revisit casting portlets as such resources.
 WSRF expected timeframe is late 2005 with
marketplace support expected in 2006.
Improved Property Support
 v1 included customization properties

Insufficiently developed to make fully functional (This is a
comment relative to portals trying to auto-generate a UI from a
PropertyDescription. Is this the relevant use case? Should
there be a means to fetch a fragment for inputting property
values (If so, are the values transparent to the Consumer?)?)
(What is missing from JSR168 properties? From other property
systems?)
 v2 may add navState and scoped transient
properties
 If not added in v2, these should be modeled in v3

Would provide a cleaner solution than simply leveraging
extensions (i.e. ba.com solution using WSRP)!
Composite Applications
 Coherent (vertical)
applications are managed
as a single entity
Develop and distribute a
complex composite application,
which comprises individual
Portlets
 Deploy the entire application on
the target system as a single
entity in one step

Composite Applications
 Can consist of





Portlets, even from different “domains”
Layout description
Pages? Even hierarchies?
Event wiring?
Common Application Context
– may fit well with transient properties and be just a scope?
 Consumers can integrate such applications as a whole

Expand from portlet as single disconnected applications to easy to consume
composite applications
Expose Aggregates as a Portlet
 Consider the std email app:
Expose Aggregates as a Portlet
 Consider the std email app:
Set of related functions, composed for usability
– Composition often includes things like coordination
 Portlets often developed together:
– Could argue this is a portlet with a set of JSP-like components for
generating each type of view, but it could just as easily be three portlets.
– Often uses some internal communications to coordinate
 Such a composition could be exposed as a WSRP v1 portlet as there is a single
set of customization parameters, etc

Expose Aggregates as a Portlet

Other cases:


Purchasing dept composes POBuilder:
1. Order summary (note: reused in other compositions)
• What items are currently on a PO (purchase order)
2. Composite catalog
• Searchable list of approved items (multiple vendors)
3. Catalog item view
• Item view/description provided by the vendor for a selected item
(Note: this could be surfacing of one of a set of portlets running on
the vendors’ systems)
Employees allowed add POBuilder to any intranet page (leveraging WSRP).
– Each portlet has different customizations/help screens => Aggregate
needs to be able to place nested-title-bars in similar style to the containing
page.
Leverage WSN
 WSN leverages WSRF to add an asynchronous notification model.
This could be useful to WSRP for:



MetadataChanged notifications
Cache update/invalidation
…
 Standard expected in late 2005 to early 2006.
Use case->Feature list
1. Theme: Portlets as UI services
2. Functional needs
a.
b.
c.
d.
e.
Content extension points
Consumer resources (e.g. referencable buttons, browser framework, etc)
Popup windows
Generating URLs to other portlets
Extendable render URLs
3. Infrastructure needs/alignment
a.
b.
c.
d.
e.
Leverage WSRF – Portlets as resources
Improved property support – make properties more useful
Composite applications – expand to consumable composites
Expose aggregates as a Portlet – v1 supports non-portal like aggregates
Leverage WSN – Async notifications (e.g. MetadataChanged, CacheUpdate)
Embedding content
 Leverage Consumer resources for defining where
portlets can insert markup

Define a well-known resource for this definition?
 Leverage Events for Consumer notifications?

Add well-known Consumer generated events?
 Add event metadata to registration?
Consumer Resource Features
 Multiple Consumer Resource needs

Reuse of Consumer provided markup (e.g. form controls, script
methods?)
 Programmatic access to Consumer services
 URL access to Consumer services (e.g. store a document in a
repository)
Consumer provided resources/markup
 Metadata needs



Valid for what markup types?
Descriptive text
Parameters -> leverage PropertyDescription?
 Runtime needs

Item’s name
Maintain single parse characteristic
– Prefix with wsrp_rewrite#
Parameter name
– Close with /wsrp_rewrite, same as for URLs
 Specifying parameters
Parameter value
– Leverage XML, name=resource/parameter name, value=value to
apply
 Example: wsrp_rewrite#<formControl><OKonclick>js event
handler</OKonclick><CancelURL>renderURL</CancelURL>
</formControl>/wsrp_rewrite
Access to Consumer services
 Leverage WSDL to describe the available services
 Also need a localized description?
 Will portlets need to indicate they have a dependency
on the Consumer providing certain services?
URL access to Consumer services
 Use template processing concepts for parameterization
 Need localized description of service
 Example:

<ConsumerURL>
<LocalizedString xml:lang=“en” resourceName=“storeDoc” value=“URL for
storing a document. Use ‘parm1’ to specify the document’s name and
‘parm2’ to specify the desired folder. Note that if a folder by that name does
not exist, one will be created.”/>
<ResourceList />
<Template>
http://www.consumer.url?action=store&name={parm1}&folder={parm2}
</Template>
</ConsumerURL>
Popups
 Using a windowState introduces protocol scope issues if the
“parent” and “popup” portlets want to do browser based
communication (common requirement).
 Defining a CC/PP profile for a Consumer supplied script
method that opens a window in a manner which allows
communication to flow back through the Consumer, inheriting
contextual information, could provide a solution.

A TC defined profile would provide a reliable way for portlets to
determine if such functionality is available
 Other interesting profiles as well?
 If a popup is a view onto the same portlet, the two
views share session state, etc (not navState)
URLs to other portlets
 New url parameter; portletHandle: References the
portlet whose view should be shown



Can’t be CCP for this end-user => POP handle
– Consumer to map to the correct CCP handle
If URL parameter is missing => use Portlet that generated the
URL
The referenced portlet replaces the portlet on the page.
[If not popping up a new window]
 Are there also use cases for referencing portlets
from other Producers?

How would the Portlet discover (and/or reference) such portlets
from a Consumer perspective?
 What about referencing other Consumer pages?
Extendable Render URLs
 URLs often have several components:

Consumer oriented:
– Base url to route processing to the right component
– State related to the End-User’s use of the “page”
 Portlet oriented:
– Identify the target portlet
– Parameters for the portlet’s processing of the url activation
 Allow logic running in the user agent to extend the render url
with additional parameters:


Leverage setting of navigational parameters on URLs?
Allow means for arbitrary extensions that only get supplied to the target
portlet? (equivalent of form parameters on pbia)
Leverage WSRF
 Expose portlets directly as WS-Resources
rather than indirectly through Producer


Recast many items as WSRF properties
– Customization properties
– Metadata
– Navigational parameters?
– Transient Properties
Use WSRF lifetime definitions for portlet leasing
– Could also be used with other resources if they are
also cast as WS-Resources
Improve Property support
 What is needed?

Assist portals in generating UIs for entering property values?
 Additional lifetimes? (i.e. are all the interesting ones covered
by navigational parameters and transient properties)
Leverage WSN
 Provides well-defined means for subscribing to and
receiving notifications:


Metadata changes
Cache update (just invalidation?)