OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [wsia] RE: [wsrp-interfaces] [wsrp][interfaces] Statemanagement/paramet ers

Sorry - it should read

"session state can possible be shared among multiple entities within a

Best regards
Carsten Leue

Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

|         |           Rex Brooks       |
|         |           <rexb@starbourne.|
|         |           com>             |
|         |                            |
|         |           07/24/2002 10:24 |
|         |           PM               |
  |                                                                                                                                                  |
  |       To:       Gil Tayar <Gil.Tayar@webcollage.com>, Carsten Leue/Germany/IBM@IBMDE                                                             |
  |       cc:       wsrp-wsia <wsia@lists.oasis-open.org>, interfaces <wsrp-interfaces@lists.oasis-open.org>                                         |
  |       Subject:  [wsia] RE: [wsrp-interfaces] [wsrp][interfaces] State  management/paramet     ers                                                |
  |                                                                                                                                                  |
  |                                                                                                                                                  |

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?


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:CLEUE@de.ibm.com]
>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
>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
>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
>- session state can possible be shared among multiple producers
>I think that it is more or less a design decision of the implementor of
>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÷blingen , 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-interfaces@lists.oasis-open.org>,
>wsrp-wsia <wsia@lists.oasis-open.org>
>   |       cc:
>   |       Subject:  RE: [wsrp-interfaces] [wsrp][interfaces] State
>management/paramet       ers
>   |
>   |
>Do you consider "navigationalState/markupParams..." and whatever to be
>stored by the Consumer, and therefore "bad". If you do, then a Portlet
>_must_ be stateful.
>-----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
>    In case Rex's message didn't clarify.  What my note was addressing was
>interest on some parties to define a "stateless" portlet as one that has
>session state but wants the session state maintained by the
>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
>in this revision of the specification because it creates mucho problems
>consumer -- basically scalability suffers in a load balanced environment
>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
>>  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
>>  whether sessionId can be collapsed into the markupParams.  This message
>>  provides an overall analysis of the general question of state
>>  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
>>  not represented/maintained by the client, rather it is maintained by
>>  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
>>  portlet.  I.e. in our protocol a single user action results in two
>>  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
>>  redirects from performAction).  Such parameters are presented by the
>>  Portal on subsequent use to both a portlet's performAction [if an
>>  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
>>  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
>>  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
>>       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
>>  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
>>  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 * rexb@starbourne.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC