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


Thanks for the clarification.

Ciao,
Rex

At 9:12 AM +0200 7/25/02, Carsten Leue wrote:
>Sorry - it should read
>
>"session state can possible be shared among multiple entities within a
>producer"
>
>
>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?
>
>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: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
>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÷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
>>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>
>>
>>----------------------------------------------------------------
>>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


--
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