Re: [wsia] RE: [wsrp-interfaces] [wsrp][interfaces]Statemanagement/paramet ers

[Michael Freedman <Michael.Freedman@oracle.com>]

Alan,
   A problem in allowing performAction to arbitrarily return markup is that
currently performAction is being reserved as the likely location for sending
events/messages to other portlets.  In such a thing comes to pass its likely we
will want semantics where all the eventing/messaging completes before any
rendering is done.
    Note: this doesn't prevent us from considering optimizing our protocol and
allowing performAction to return markup in well defined situations -- I think
this may have been the intent of the original proposal.  Personally, I am not
convinced we should do this (yet).

   On your second question, yes, the way I have described things we wouldn't
need a duration on markupParams as their lifetime is well defined.
      -Mike-

Alan Kropp wrote:

> See <AK></AK> below..
>
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Friday, July 19, 2002 8:42 AM
> To: interfaces; wsrp-wsia
> Subject: [wsrp-interfaces] [wsrp][interfaces] State
> management/parameters
>
> Folks,
>    At the F2F I took on the task to clarify the proposed support for
> "stateless" entities.  In the meantime a discussion has ensued regarding
> whether sessionId can be collapsed into the markupParams.  This message
> provides an overall analysis of the general question of state management
> and its relationship to the protocol.  Based on this a particular
> usage/semantic pattern is proposed.  Its intent is to clarify both of
> the above issues.  Please let me know what you think.
>
> Through various discussions/analysis 4 types of state can be defined.
> The first three are well understood web application states/styles.  The
> last is a new one that comes into existence because of the way our
> protocol works:
> 1) Navigational (URL) state -- this is state represented as parameters
> in the query strings of links that establish the "navigational context"
> of a page.  I.e. this is the state that allows a link to encode the
> state of a page so it may be bookmarked, refreshed, navigated to via
> next/back.  An example of this is the amazon.com link that references
> the page that describes a specific book. The parameters for this
> reference are part of the link making it bookmarkable/navigatable etc.
> 2) Session state -- this is user application state that doesn't vary as
> you navigate.  An example is your shopping cart in amazon.com.  The
> items in your shopping cart don't change as you use the next/prev
> buttons or redisplay.  Unlike navigational (URL) state, session state is
> not represented/maintained by the client, rather it is maintained by the
> server.  The client merely has a reference to this state.  This
> reference is typically in a cookie but can also be a URL parameter
> itself.
> 3) Action (transient) state -- this is state passed on requests that is
> meant to be processed (submitted) and then tossed -- though the
> processing usual results in changes to either session or navigational
> state.  The example for this is form submission.
> 4) Request (transient) state -- this is intermediate state meant to be
> created during action processing and used in the next render call of the
> portlet.  I.e. in our protocol a single user action results in two calls
> to the portlet performAction and getMarkup.  These two calls occur
> across 2 (connectionless) SOAP calls.  How does a portlet create
> transient state in an action that is can access in the following render
> while not needing to clean it up because it is recollected after the
> "request" completes?  I.e. in the servlet model during a single request
> logic can attach transient request state for later logic via request
> Attributes.  How does this work between an action/render pair in our
> protocol?  Answer: invent/support request state.
>
> <AK>
> I wonder if we really need to express this in the protocol.  I think there
> has
> been some discussion around performInteraction returning markup itself.
> Essentially,
> the portal invokes performInteraction, and based on the portlet
> implementation this
> MAY return markup.  The portlet "knows" whether it should render
> in response to a change in its transient state, so
> leave it up to the portlet to optionally generate markup, and save the
> additional roundtrip.
>
> I'm not attempting to re-open the prior discussion around whether we need a
> separate
> action interface.  I do like the flexibility (for the portlet developer) to
> expose
> actions in the service interface...but I also want network efficiency, so
> allow the developer to specify actions
> that may (not) render markup, and the portal need only worry about making a
> single
> invocation that MAY return markup.
> </AK>
>
> How should our protocol present the above styles/usages?
> 1) Navigational (URL) state is represented by query string parameters
> added to links generated by the portlet in its response to getMarkup (or
> redirects from performAction).  Such parameters are presented by the
> Portal on subsequent use to both a portlet's performAction [if an action
> url] and getMarkup calls as request parameters (in the RequestContext).
> They are always resubmitted on redisplay.
> 2) Action state is represented distinctly from navigational state by URL
> parameters added to action links generated by the portlet in its
> response to getMarkup.  I.e. action parameters and navigational
> parameters coexist in a link and can be distinguished by the portal.
> Action parameters are only presented by the Portal on subsequent use to
> a portlet's performAction.  They are not presented to getMarkup.  They
> are passed to performAction as interactionParams.
> 3) Session state is maintained by the portlet as needed and reacquired
> on request by reference (i.e. a sessionID is passed to all portlet APIs
> including performAction and getMarkup so it reattach to its in memory
> state) [See below for note on why I suggest we don't support having the
> Portal maintain this state on behalf of the portlet and resupply on each
> request].
> 4) Request state is an opaque value returned by a performAction call to
> the Portal and based to [only] the next getMarkup of that entity.  This
> state is represented by the markupParams returned by performAction and
> passed to the next getMarkup.  getMarkup wouldn't return markupParams --
> its navigational parameters/state would be encoded in its response
> links.
>
> Note:  In the F2F we discussed supporting "stateless" portlets.  At the
> time we attempted to model not only "stateless" portlets as those that
> limit themselves to be represented merely by navigational state (URL
> parameters) but also session state.  I.e. one form of markupParams was
> to allow a portlet to package its session state and return it to the
> Portal for later submission rather then keep this information in memory
> and merely return a reference (sessionID).  I recommend we do not add
> this functionality to version 1 of the specification [though we could
> discuss dropping altogether from further consideration].  There are
> three reasons for this recommendation:
>      a) this "function" is not currently readily modelled in the web
> world.  Returning session state to the client prevents effective
> bookmarking/navigation.
>      b) adding this function complicates the API -- as sessionID covers
> the session state case why worry now about supporting a new/extra model?
>
>      c) having the portal maintain the session state vs a session
> reference has negative performance/scalability implications.  When a
> portal is running in a load balanced environment state managed on behalf
> of the portlet/entity must be maintained in a manner so all nodes see a
> common/consistent view of this state.  In such a world writes (the time
> when state returned by the portlet has changed and needs to be rewritten
> to the shared state manager) are generally expensive.  Session
> references rarely change (are good).  Session state changes frequently
> (often on every request) and is therefore bad.
>
> <AK>
> So does this moot the discussion about returning a "duration" with the
> markupParams?  If session state is managed by the Producer, there's nothing
> the Consumer is holding on to that a duration "hint" from the Producer would
> apply to.  Certainly cleaner in my view.
> </AK>
>
>         -Mike-
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>