Re: [wsrp-interop] on initCookies and sessionID

[Subbu Allamaraju <subbu@bea.com>]

Good point. It does simplify Alejandro's scenario for the Consumer.

Subbu

Rich Thompson said the following on 11/19/2003 11:58 AM:
> 
> I would encourage the Producer in such a scenario to only use the cookie 
> and never return a sessionID. This eliminates duplicate information that 
> can cause all sorts of issues.
> 
> Rich
> 
> 
> *Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>*
> Sent by: Alejandro.Abdelnur@Sun.COM
> 
> 11/19/2003 01:43 PM
> 
> 	
> To
> 	wsrp-interop@lists.oasis-open.org
> cc
> 	
> Subject
> 	Re: [wsrp-interop] on initCookies and sessionID
> 
> 
> 	
> 
> 
> 
> 
> 
> This was exactly the scenario we are facing. The problem is that things  
> get weird (out of synch) if the consumer invokes the producer in  
> parallel for 2+ portlets and one of the throws a cookie or a session  
> fault.
> 
> Alejandro
> 
> On Wednesday, November 19, 2003, at 06:08  AM, Subbu Allamaraju wrote:
> 
>  >
>  > I would like to note that a Producer requring perUser init cookies may  
>  > choose to use the same cookie for both cases (ie return a session  
>  > cookie in response to an initCookie call, and return the same session  
>  > ID in the pbia response).
> 
>  > In this case, my interpretation is that
>  >
>  > (a) Producer returns InvalidCookie fault when the cookie from the  
>  > request (when HTTP binding is used) is no longer valid.
>  >
>  > (b) Poducer never returns InvalidSession fault (since this has the  
>  > same affect, atleast for the Producer), and reinvoking initCookie()  
>  > and resupplying data stored in sessions lets the Producer/portlet  
>  > recover from session loss.
>  >
>  > For the consumer,
>  >
>  > (a) If the Consumer is strict about cookies, it does not send expired  
>  > cookies to the Producer. So, after the cookie times out, it  
>  > automatically invokes initCookie().
>  >
>  > (b) If the Consumer is not strict, it may send an expired cookie to  
>  > the Producer. The producer then returns InvalidCookie fault.
>  >
>  > Subbu
>  >
>  >
>  > Rich Thompson said the following on 11/19/2003 05:52 AM:
>  >> My take on the answers:
>  >> First, overall comments: Private sessions between the end-user and  
>  >> particular instances of a portlet are modeled in the protocol via  
>  >> sessionID. It was also recognized that various systems have reasons  
>  >> to use a cookie to carry session information, though these types of  
>  >> sessions are not always unique to a portlet instance. As a result,  
>  >> these two tend to closely parallel each other while never being  
>  >> linked.
>  >> Q1. Is there any required relationship between the cookies returned  
>  >> by initCookie and the sessionID returned by the markup interface  
>  >> calls?
>  >> A1. No, though if the CookieProtocol is perUser then they do carry  
>  >> the same semantics.
>  >> Q2. If a call returns an InvalidCookie fault, should the consumer  
>  >> discard the sessionID?
>  >> A2. No, the cookies are independent of the private sessionID and are  
>  >> not necessarily related to a session at all.
>  >> Q3. If a call returns an InvalidSession fault, should the consumer  
>  >> call initCookie again?
>  >> A3. same as A2.
>  >> Sorry if the fault descriptions are confusing:
>  >>  - InvalidSession fault is used only when the private session has  
>  >> timed out and required data had been cached in the session (templates  
>  >> or UserContext). If the session did not contain such data or it is  
>  >> also available via the supplied data on the invocation, the Producer  
>  >> can simply create a new session and include it in the returned data  
>  >> structure for future invocations from the Consumer.
>  >>  - InvalidCookie fault is used only when the cookies established by  
>  >> initCookie become invalid. This signals to the Consumer the need to  
>  >> invoke initCookie again. Since some Producers will establish a  
>  >> session related to these cookies, it would be wise for the Consumer  
>  >> to resend templates and UserContext when reinvoking the operation  
>  >> that caused the InvalidCookie fault as this can avoid the next  
>  >> invocation returning an InvalidSession fault.
>  >> Rich
>  >> *Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>*
>  >> Sent by: Alejandro.Abdelnur@Sun.COM
>  >> 11/18/2003 07:02 PM
>  >>                  
>  >> To
>  >>                  wsrp-interop@lists.oasis-open.org
>  >> cc
>  >>                  
>  >> Subject
>  >>                  [wsrp-interop] on initCookies and sessionID
>  >>                  
>  >> One of the engineers in my group (punished with implementing WSRP)  
>  >> came
>  >> to me with the following questions and I could not find an answer for
>  >> her. I would like to know what is your opinion on this and how are you
>  >> handling this scenario.
>  >> Thanks
>  >> Alejandro
>  >> * Producer requires initCookie.
>  >> * Consumer uses more than one portlet from the producer for
>  >>   the portal page of a user.
>  >> * initCookie has been called upfront.
>  >> * performBlockingInteraction and/or getMarkup have returned a  
>  >> sessionID
>  >> Q1. Is there any required relationship between the cookies returned by
>  >> initCookie and the sessionID returned by the markup interface calls?
>  >> Q2. If a call returns an InvalidCookie fault, should the consumer
>  >> discard the sessionID?
>  >> Q3. If a call returns an InvalidSession fault, should the consumer  
>  >> call
>  >> initCookie again?
>  >> If the answer is 'no' to all the questions, then the following  
>  >> sections
>  >> of the spec make things more confusing:
>  >> P27/L27 "If the Producer returns an InvalidSession fault message after
>  >> returning a sessionID, the Consumer MUST NOT resupply that sessionID  
>  >> on
>  >> a subsequent invocation and SHOULD reinvoke the operation that caused
>  >> the fault message without any sessionID and supply any data that may
>  >> have been stored in the session."
>  >> P44/L6 "If at any time the Producer throws a fault message
>  >> (“InvalidCookie”) indicating the supplied cookies have been  
>  >> invalidated
>  >> at the Producer, then the Consumer MUST again invoke initCookie() and
>  >> SHOULD reprocess the invocation that caused the fault message to be
>  >> thrown and include any data that may have been stored in a session
>  >> related to a cookie"
>  >> P77/Table,Row=InvalidCookie "InvalidCookie Used only when the
>  >> environment at the Producer has timed out AND the Producer needs the
>  >> Consumer to invoke initCookie() again and resend data that may have
>  >> been stored in sessions related to a cookie."
>  >> P77/Table,Row=InvalidSession "Used only when a Producer session has
>  >> timed out AND the Producer needs the Consumer to invoke resend data
>  >> that may have been cached in the session."
>  >
>  >
>  >
>  > To unsubscribe from this mailing list (and be removed from the roster  
>  > of the OASIS TC), go to  
>  > http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/
>  > leave_workgroup.php.
>  >
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
> 
>