Getting Portlet Description Current Options Using Service Description

Getting Portlet Description

Current Options • Using Service Description interface, – Obtain the full Service. Description from the Producer – Search offered. Portlets array for descriptions of specific portlets • Using Portlet Management interface, – Get the description of a POP or CCP

Motivation • Not all Consumers cache full Service Description – Must get full Service. Description every time a Portlet. Description is needed • Consumers must search for description of a given portlet – Time consuming with large Producers – Slows down user interfaces • Portlet registry – Must get full Service Description once a portlet is found in a registry

Use Case – 1 • Get minimal description of portlets – 1. Consumer provides a user interface for portlets offered by a Producer – 2. Consumer does not need the full description of portlets to display a list of portlets – 3. When a user selects a portlet, Consumer would like to obtain the full description of the portlet

Use Case 2 • Registry Use Case – 1. Consumer user searches for portlets in a registry (UDDI or eb. XML) using some search criteria – 2. User selects a portlet to view its capabilities and properties – 3. Consumer would like to obtain the full description of the portlet based on its portlet. Handle

Misc Use Cases • 1. Producer can choose to provide minimal Portlet Description. But the Consumer has no choice to specify whether it needs full/minimal description of some or all portlets • 2. Get portlet description without supplying a user context. The get. Portlet. Description operation requires a user context.

Goals • 1. Get descriptions of one or more portlets • 2. Get minimal or full descriptions • 3. No dependency on a portlet registry for minimal description of a portlet • 4. Piggy-back on existing operations

Proposal - get. Service. Description = get. Service. Description( Registration. Context, desired. Locales, portlet. Description. Level, portlet. Handles); • portlet. Description. Level – filter – “minimal”: Producer SHOULD return minimal description of portlets – “full”: Producer SHOULD return full description of portlets – Soft filter (SHOULD) – Defaults to “full” (i. e. , WSRP 1. 0 behavior) • portlet. Handles – one or more portlet. Handles – Producer limits the offered. Portlets array to the supplied portlet. Handles – Hard filter – If not supplied, defaults to WSRP 1. 0 behavior

Proposal - get. Portlet. Description. Response = get. Portlet. Description( Registration. Context, Portlet. Context, user. Context, desired. Locales, portlet. Description. Level); • portlet. Description. Level – filter – “minimal”: Producer SHOULD return minimal description of portlets – “full”: Producer SHOULD return full description of portlets – Defaults to “full” (i. e. , WSRP 1. 0 behavior)

Open Questions – 1 • What is “minimal” portlet description? – Currently, Portlet. Description must include portlet. Handle and at least one mime. Type with at least one window. State and mode. • Does not require descriptive information such as description, title, keywords etc. – Option 1: Spec to specify minimal description to include some descriptive elements (such as description and title) • Pros – Consistent behavior across Producer implementations • Cons – More work for Producers – Migration of portlets from WSRP 1. 0 to WSRP 2. 0 – Option 2: Producer chooses some minimal attributes • Pros – Simpler for Producer implementations • Cons – Does not fully meet the use cases

Open Questions - 2 • Move get. Portlet. Description from Portlet Management interface to Service Description interface – Pros • Addresses some of the use cases • Will have to enhance for other use cases – portlet. Description. Level – portlet. Handles – Cons • Interface change • Will have to account for CCPs as well