1 / 17

V2 Framework Update

V2 Framework Update. 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

Download Presentation

V2 Framework Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related