[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC