[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-interfaces] Re: [wsia] [wsrp][interfaces] Statemanagement/parameters
This is a restatement of purposes for the different classes of state to
make sure I understand the distinctions combined with how we have been
mapping the different types of state:
1) Navigational State - This is what enables the entity to correctly
generate the markup, both initially and/or on a refresh or reload from a
bookmark. Typically this is stored in the URL, but since the entity does
not have direct access to the URL we introduced the markupParams structure.
2) Session State - This is a reference to state stored locally by the
entity. One question under debate is whether the protocol needs to carry
this separately or will just require the entity to place it within the
markupParams structure.
3) Action State - The current draft carries these as 'clientParameters' in
the RequestContext structure and anticipates (but doesn't state) that they
would be specified on the URL causing the action to be invoked.
4) Request State - This is the state coming out of performInteraction()
that allows getMarkup() to correctly generate markup. Doesn't this just
collapse into #1 so that a page refresh also returns the correct markup?
Your comments about performance in a clustered environment are well taken
... aren't they really just a matter of clearly distinquishing between
these 3 types of state so that highly scalable systems can be built? The
other way I could read your note is to try and take the navigational state
out of the protocol. About the only way I could see that doing what the
End-User expects from a bookmark would be if the Consumer was informed when
the bookmark was generated such that an Entity could be generated to
represent the current state (ie. would also have to introduce semantics for
persisting what is now transitory state so that it may be reused when the
bookmark is activated). This would be significant additional semantics and
I doubt that browsers normally inform the server when a bookmark is
generated (though clearly some JavaScript could do this on high end
browsers).
Michael Freedman
<Michael.Freedman@ To: interfaces <wsrp-interfaces@lists.oasis-open.org>,
oracle.com> wsrp-wsia <wsia@lists.oasis-open.org>
cc:
07/19/2002 11:41 Subject: [wsia] [wsrp][interfaces] State management/parameters
AM
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC