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

[Gil Tayar <Gil.Tayar@webcollage.com>]

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>