v2 framework update

WSRP Technical Committee

V2 Framework Update


V1 FrameworkDiscovery => Consumer discovers Producer’s capabilitiesRegistration => Consumer tells Producer how it plans to use itConfiguration => Consumer can customize the Portlets of the ProducerPage Load => Markup retrieved, possibly session initializationUser Interaction

Perform logical action: performBlockingInteraction() Load new page: getMarkup()

Cleanup User log off: releaseSessions() Orphaned portlet clones: destroyPortlets() End relationship: deregister()


V2 => Framework UpdateDiscovery => Consumer discovers Producer’s capabilitiesRegistration => Consumer tells Producer how it plans to use itConfiguration => Consumer can customize the Portlets of the ProducerPage Load => Markup retrieved, possibly session initializationUser Interaction

Perform logical action: performBlockingInteraction() Load new page: getMarkup()

Cleanup User log off: releaseSessions() Orphaned portlet clones: destroyPortlets() End relationship: deregister()

Greater set of std capabilities to

advertiseMore things can be

configured

Could involve initializing runtime

state

Can return “logical events”

New step for distributing “events”

New step for “end” of user interaction?


V2 FrameworkDiscovery => Consumer discovers Producer’s capabilities (increased set of std capabilities to advertise)Registration => Consumer tells Producer how it plans to use itConfiguration => Consumer can customize the Portlets of the ProducerPage Load => Initialize runtime state (if desired), Markup retrieved, possibly session initializationUser Interaction

Perform logical action: performBlockingInteraction(), ... Distribute coordination info to Portlets Load new page: getMarkup()

On “EndUserInteraction”, potentially retrieve end stateCleanup

User logs off: releaseSessions() Orphaned portlet clones: destroyPortlets() End relationship: deregister()


Needed Changes?

How to realize these framework changes?


Possible Coordination models

1. Runtime state (equivalent of bean properties) Use a generic description model and generic

operations.

2. Events (equivalent of bean events) Use a generic description model and a generic

operation.

3. Allow both Permit developers to use the programming model

they are most comfortable with. Some aspects of applications are easier to model in

one of the two models though one can always map those to the other.

Provide Consumer flexibility in what is supported.


V2 – Runtime state

The SC has agreed that runtime state should be part of the overall coordination model.Will develop API and semantics using “StateValue” and determine later whether or not this can merge cleanly with the current “Property” concept as this is not covering persistent configuration data. Portlet publishes a description of a portion of its data

model that is willing to expose to the outside world. Portlet notifies Consumer when state changes occur. Consumer chooses when to pull and push state changes.

Whenever possible, coordination information will be provided in a “piggy-backed” fashion on other operations.


V2 – Events

The SC has agreed that the overall coordination model should also include portlet-defined events. Portlet publishes a description (both name and data type) for

the events it generates and those it consumes. Consumer manages the dispatching of events, optionally

providing a mapping for disparate event types.

The SC realizes that events might be needed outside of a user-interaction cycle (e.g. initialization).Whenever possible, coordination information will be provided in a “piggy-backed” fashion on other operations.We will not be concerned with out-of-band events for now May be required to support invalidation caching.


V2 – Event Delivery Operation

In: registrationContex

t portletContext runtimeContext userContext events[] mode? windowState? navigationalState?

Out: events[] sessionContext portletContext newMode? newWindowState? navigationalState? markupContext?

(how can the portlet know if it is safe and reasonable to return markup?)

handleEvents() => in Markup portType


Following slides are from a strawman proposal to the SC

and have not been thoroughly reviewed or

approved


V2 – Runtime state model

Operations return an array of StateValues: performBlockingInteraction getStateValue setStateValue (Note: all have to be in the Markup portType)

PortletDescription has an array of StateValueDescriptions for names and types of exposed StateValues

Strawman


V2 – Event model

Operations return an array of generated events performBlockingInteraction handleEvents (Note: all have to be in the Markup portType)

PortletDescription has an array of EventDescriptions for:

raisedEvents handledEvents

EventDescriptions describe: Event name Data payload of the event …

Strawman


V2 – Layered Coordination Model

Carry StateValue changes as events? wsrp:StateValueModified – raised event wsrp:UpdateStateValue – handled event

Reduces developer learning curve to a single modelRequires Consumers support full coordination model

Strawman


V2 – Some open questions

1. Keep State and Event coordination models separate or layer them?

2. Should senders and receivers of coordination information be aware of each other?

3. Should a user interaction be able to directly cause event or state update distributions?



4. Should the WSRP protocol be concerned about loop avoidance?

5. Do we want to do coordination subscriptions? Consumer would indicate what events (or state changes)

it would like to receive: ReturnAny subscribe(registrationContext, portletContext,

runtimeContext, names[])

ReturnAny unsubscribe(registrationContext, portletContext, runtimeContext, names[])

Producer should only forward requested notifications

6. What processing model constraints would be required for Consumers to efficiently distribute state changes?



7. Should portlet-specific operations be exposed to the Consumer?

8. Should the Consumer indicate whether or not it thinks it is safe for a Portlet to return markup?

9. Would adding incoming coordination information to getMarkup() make sense?



10.Would any advanced query capabilities make sense?

11.How close to the bleeding edge of leveraging other standards (Grid, WS-*, etc) do we want WSRP?

12.Should the protocol be concerned with state recovery when a user interaction cycle fails to complete normally?1. Possibility is to add startCycle, endCycle and

cycleFailed events

v2 framework update

Documents