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

["Tamari, Yossi" <yossi.tamari@sap.com>]

Hi Mike,

Regarding "action parameters and navigational parameters coexist in a link and can be distinguished by the portal":

How are we going to distinguish between the two? This could very easily become confusing for developers.
Does this model require rewriting all existing portlet to support it (since the container cannot do this for the portlet)? If this is the case I would say this is a huge drawback.
How do we support this model when we already know that this will not work with some browsers/devices (because the URLs will tend to be long, especially if we don't support stateless stateful portlets...)?

	Yossi.

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Friday, July 19, 2002 6:42 PM
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>