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 events to coordinated 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. Proposed Changes Proposal for realizing these framework changes WSRP Technical Committee

6. V2 changes - Properties • Extend Property concept to cover transparent transient state. Options discussed to-date: • Add scope attribute to ModelDescription type. This would add support for multiple models, each existing for a different lifetime. • Add scope attribute to PropertyDescription type. This describes the lifetime on a per property basis. • Define scopes for: • configuration (better term needed … persistent?, registration?, ??) • session • request • Add access attribute to PropertyDescription. Define: • readWrite (default) • readOnly • writeOnly? (equivalent to an input parameter when scope=request) WSRP Technical Committee

7. V2 changes - Events • Descriptive and runtime types • EventDescription type • eventName (attribute) - QName • eventType (attribute) – QName of a type • description (element) • any (extensibility element) • Event type • eventName (attribute) - QName • eventType (attribute) – QName • eventNum (attribute) – xsd:int => allows receiver to drop duplicates • any (payload) • Loop prevention needs? WSRP Technical Committee

8. V2 changes - Events • Defined event names: • wsrp:PropertyModified • EventType carries property name, old value and new value? • wsrp:PropertyInserted • EventType carries property name, type and initial value? • wsrp:PropertyRemoved • EventType carries property name and final value? • wsrp:InteractionComplete • EventType carries ?? WSRP Technical Committee

9. V2 changes –“piggy-back” event notification • Add PerformBlockingInteractionResponse.events[] • Other options include: • Define an EventSink portType that the Consumer implements. Invocations are during the interaction processing. • Directly wire portlets to each other. WSRP Technical Committee

10. V2 changes - PortletDescription • Add PortletDescription.generatedEvents • Add PortletDescription.processedEvents WSRP Technical Committee

11. V2 changes - Distributing Events • Property oriented events can be handled through setProperty() • Portlet-specific events => add new operation • events[] handleEvents(registrationContext, portletContext, runtimeContext, events[]) • Add this to the Markup portType so that cookies and sessions work on clustered Producers. WSRP Technical Committee

12. V2 changes - Event Subscription • Consumer indicates what events it would like to receive: • ReturnAny subscribe(registrationContext, portletContext, runtimeContext, eventNames[]) • ReturnAny unsubscribe(registrationContext, portletContext, runtimeContext, eventNames[]) • Producer should only forward requested events • Should Consumer also indicate how it would like to receive events? (callback, WSRP, …) WSRP Technical Committee

13. V2 changes - Not Addressed • Would adding an incoming eventList to getMarkup() make sense? • Coordination via portlet specific operations • How is Consumer informed about the semantic meaning of a particular set of invocation parameters? • Leveraging grid standards (has already worked on eventing issues and some of these efforts appear to be headed into the infrastructure as WSDL extensions) • All extend a portType that inherently uses leasing • All event definitions are in the grid extensibility arena (i.e. WSDL per portlet) • WSRP Producer could map to the grid Factory and HandleResolver concepts with portlets mapped to grid service instances. • Enabling efficient Consumer distribution of events: • What additional metadata or runtime data would be needed? • Would more advanced query capabilities make sense? WSRP Technical Committee

14. V2 changes – Other possible operations • Models • getModels() • setModels() • Interaction processing • performInteraction() • setProperties() – how to indicate on portlet URL? WSRP Technical Committee