Re: [wsrp-interfaces] [wsrp][interfaces] State management/paramet ers

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

No we won't require portlets be stateful. I believe that navigationalState can
be defined in a useful way yet allow the consumer to employ techniques that
allow this state to be stored in the client (rather then itself) yet not impact
concurrency of the consumer's aggregator.

I have asked someone in my team to put together an e-mail that illustrates this.

    -Mike-

Gil Tayar wrote:

> Do you consider "navigationalState/markupParams..." and whatever to be state
> stored by the Consumer, and therefore "bad". If you do, then a Portlet
> _must_ be stateful.
>
> Gil
>
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Wed, July 24, 2002 00:28
> Cc: interfaces; wsrp-wsia
> Subject: Re: [wsrp-interfaces] [wsrp][interfaces] State
> management/paramet ers
>
> Gil,
>    In case Rex's message didn't clarify.  What my note was addressing was
> the
> interest on some parties to define a "stateless" portlet as one that has
> session state but wants the session state maintained by the client/consumer
> vs
> maintaining it itself in memory [and just having the client/consumer
> maintain a
> reference/session id to this state].  I suggested we NOT support such a
> thing
> in this revision of the specification because it creates mucho problems for
> the
> consumer -- basically scalability suffers in a load balanced environment if
> the
> state being managed changes frequently.  Session IDs/reference change
> infrequently [good].  Session state changes frequently [bad].
>     -Mike-
>
> Gil Tayar wrote:
>
> > Mike,
> >
> > Great summary _and_ proposal. I think you hit the nail on the spot.
> >
> > On your "note". I'm not sure I understood it. Actually, I didn't
> understand
> > it at all :-). Could you respecify the problem?
> >
> > Gil
> >
> > -----Original Message-----
> > From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> > Sent: Fri, July 19, 2002 18:42
> > 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.
> >
> > 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.
> >
> >         -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>
>
> ----------------------------------------------------------------
> 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>