I'm not understanding how a session state can be shared by multiple
producers. Is that something specific to load balancing on a server
session? If so, I assume that is distinct from shared sessionID for
an end-user or client which might have several portlets from single
producer who issues the ID?
Ciao,
Rex
At 11:07 PM +0300 7/24/02, Gil Tayar wrote:
>That's a good summary of the difference between the two.
>
>-----Original Message-----
>From: Carsten Leue [mailto:]
>Sent: Wed, July 24, 2002 22:05
>To: Gil Tayar
>Cc: wsrp-wsia; interfaces
>Subject: RE: [wsrp-interfaces] [wsrp][interfaces] State
>management/paramet ers
>
>
>Gil - my current understanding of the distinction between session state and
>navigationalState is the following:
>
>What they have in common:
>- both refer to transient state
>- both might contain information needed for navigation (e.g. the current
>page)
>
>What distinguishes them:
>- sessions might time out at any time, navigational state does not
>- session state is not bookmarkable, navigational state is
>- session state is stored on the producer, navigational state on the
>consumer. Only the sessionID the represents session state is held on the
>consumer
>- session state can possible be shared among multiple producers
>
>I think that it is more or less a design decision of the implementor of the
>service what part of the transient information to put in the session and
>what part in the navigational state. A completely stateless producer might
>well put everything in the navigational state part whereas a fat producer
>might put everything in the session (losing bookmarkability), relesing the
>consumer from storing this information.
>
>
>Best regards
>Carsten Leue
>
>-------
>Dr. Carsten Leue
>Dept.8288, IBM Laboratory B鐽lingen , Germany
>Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
>
>
>|---------+---------------------------->
>| | Gil Tayar |
>| | <Gil.Tayar@webcol|
>| | lage.com> |
>| | |
>| | 07/24/2002 08:42 |
>| | AM |
>|---------+---------------------------->
>
>>---------------------------------------------------------------------------
>-----------------------------------------------------------------------|
> |
>|
> | To: interfaces <>,
>wsrp-wsia <>
>|
> | cc:
>|
> | Subject: RE: [wsrp-interfaces] [wsrp][interfaces] State
>management/paramet ers
>|
> |
>|
> |
>|
>
>>---------------------------------------------------------------------------
>-----------------------------------------------------------------------|
>
>
>
>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:]
>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:]
>> 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>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com *
