[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