V2 Framework Update

1. V2 Framework Update WSRP Technical Committee

2. V1 Framework • Discovery => Consumer discovers Producer’s capabilities • Registration => Consumer tells Producer how it plans to use it • Configuration => Consumer can customize the Portlets of the Producer • Page Load => Markup retrieved, possibly session initialization • User Interaction • Perform logical action: performBlockingInteraction() • Load new page: getMarkup() • Cleanup • User log off: releaseSessions() • Orphaned portlet clones: destroyPortlets() • End relationship: deregister() WSRP Technical Committee

3. Greater set of std capabilities to advertise V2 => Framework Update More things can be configured • Discovery => Consumer discovers Producer’s capabilities • Registration => Consumer tells Producer how it plans to use it • Configuration => Consumer can customize the Portlets of the Producer • Page Load => Markup retrieved, possibly session initialization • User Interaction • Perform logical action: performBlockingInteraction() • Load new page: getMarkup() • Cleanup • User log off: releaseSessions() • Orphaned portlet clones: destroyPortlets() • End relationship: deregister() Could involve initializing runtime state Can return “logical events” New step for distributing “events” New step for “end” of user interaction? WSRP Technical Committee

4. V2 Framework • Discovery => Consumer discovers Producer’s capabilities (increased set of std capabilities to advertise) • Registration => Consumer tells Producer how it plans to use it • Configuration => Consumer can customize the Portlets of the Producer • Page Load => Initialize runtime state (if desired), Markup retrieved, possibly session initialization • User Interaction • Perform logical action: performBlockingInteraction(), ... • Distribute coordination info to Portlets • Load new page: getMarkup() • On “EndUserInteraction”, potentially retrieve end state • Cleanup • User logs off: releaseSessions() • Orphaned portlet clones: destroyPortlets() • End relationship: deregister() WSRP Technical Committee

5. Needed Changes? How to realize these framework changes? WSRP Technical Committee

6. Possible Coordination models • Runtime state (equivalent of bean properties) • Use a generic description model and generic operations. • Events (equivalent of bean events) • Use a generic description model and a generic operation. • 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. WSRP Technical Committee

7. 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. WSRP Technical Committee

8. 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. WSRP Technical Committee

9. V2 – Event Delivery Operation handleEvents() => in Markup portType • In: • registrationContext • 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?) WSRP Technical Committee

10. Following slides are from a strawman proposal to the SC and have not been thoroughly reviewed or approved WSRP Technical Committee

11. Strawman 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 WSRP Technical Committee

12. 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 • … WSRP Technical Committee

13. 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 model • Requires Consumers support full coordination model WSRP Technical Committee

14. V2 – Some open questions • Keep State and Event coordination models separate or layer them? • Should senders and receivers of coordination information be aware of each other? • Should a user interaction be able to directly cause event or state update distributions? WSRP Technical Committee

15. V2 – Some open questions • Should the WSRP protocol be concerned about loop avoidance? • 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 • What processing model constraints would be required for Consumers to efficiently distribute state changes? WSRP Technical Committee

16. V2 – Some open questions • Should portlet-specific operations be exposed to the Consumer? • Should the Consumer indicate whether or not it thinks it is safe for a Portlet to return markup? • Would adding incoming coordination information to getMarkup() make sense? WSRP Technical Committee

17. V2 – Some open questions • Would any advanced query capabilities make sense? • How close to the bleeding edge of leveraging other standards (Grid, WS-*, etc) do we want WSRP? • Should the protocol be concerned with state recovery when a user interaction cycle fails to complete normally? • Possibility is to add startCycle, endCycle and cycleFailed events WSRP Technical Committee