1. WSRP Technical Committee V2 Framework Update

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

3. WSRP Technical Committee V2 => Framework Update 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() Greater set of std capabilities to advertise More 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?

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

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

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

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

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

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

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

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

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

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

14. WSRP Technical Committee 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 the Consumer indicate whether or not it thinks it is safe for a Portlet to return markup?

15. WSRP Technical Committee V2 – Some open questions 4. Should the WSRP protocol be concerned about loop avoidance? 5. Should a user interaction be able to directly cause event or state update distributions? 6. What processing model constraints would be required for Consumers to efficiently distribute state changes?

16. WSRP Technical Committee V2 – Some open questions 7. Should portlet-specific operations be exposed to the Consumer? 8. Would adding incoming coordination information to getMarkup() make sense? 9. Would any advanced query capabilities make sense?

17. WSRP Technical Committee V2 – Some open questions 10. How close to the bleeding edge of leveraging other standards (Grid, WS-*, etc) do we want WSRP? 11. 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

18. WSRP Technical Committee V2 – Event model Descriptive and runtime types EventDescription type  eventName (attribute) - QName  eventType[] – QName to the EventTypeDescription  description (LocalizedString)  any (extensibility element) EventTypeDescription type  dataType – QName to a payload time  description – (LocalizedString) Event type  eventName (attribute) - QName  eventType? (attribute) – QName  eventNum (attribute) – xsd:int => allows receiver to drop duplicates  Indicator of the portlet sourcing the event?  any (payload) Loop prevention needs? Strawman