[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
I'm not convinced there is a lack of clarity in the spec in this area, but = there certainly are a number of rat holes one can get into if certain=20 implementation choices are made. Rich=20 Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>=20 Sent by: Alejandro.Abdelnur@Sun.COM 11/19/2003 01:38 PM To wsrp-interop@lists.oasis-open.org cc Subject Re: [wsrp-interop] on initCookies and sessionID The lesson learned from this one is 'Do not mistake session with=20 session' :) I think it would help if we clarify the spec on this. Thanks. Alejandro On Wednesday, November 19, 2003, at 04:52 AM, Rich Thompson wrote: > > My take on the answers: > > First, overall comments: Private sessions between the end-user and=20 > particular instances of a portlet are modeled in the protocol via=20 > sessionID. It was also recognized that various systems have reasons to=20 > use a cookie to carry session information, though these types of=20 > sessions are not always unique to a portlet instance. As a result,=20 > these two tend to closely parallel each other while never being >=20 linked. > > Q1. Is there any required relationship between the cookies returned by=20 > initCookie and the sessionID returned by the markup interface calls? > A1. No, though if the CookieProtocol is perUser then they do carry the=20 > same semantics. > > Q2. If a call returns an InvalidCookie fault, should the consumer=20 > discard the sessionID? > A2. No, the cookies are independent of the private sessionID and are=20 > not necessarily related to a session at all. > > Q3. If a call returns an InvalidSession fault, should the consumer=20 > call initCookie again? > A3. same as A2. > > Sorry if the fault descriptions are confusing: > - InvalidSession fault is used only when the private session has=20 > timed out and required data had been cached in the session (templates=20 > or UserContext). If the session did not contain such data or it is=20 > also available via the supplied data on the invocation, the Producer=20 > can simply create a new session and include it in the returned data=20 > structure for future invocations from the Consumer. > - InvalidCookie fault is used only when the cookies established by=20 > initCookie become invalid. This signals to the Consumer the need to=20 > invoke initCookie again. Since some Producers will establish a session=20 > related to these cookies, it would be wise for the Consumer to resend=20 > templates and UserContext when reinvoking the operation that caused=20 > the InvalidCookie fault as this can avoid the next invocation=20 > returning an InvalidSession fault. > > Rich > > <image.tiff> > > > > > > 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=3DInvalidCookie "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=3DInvalidSession "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." > > > --=_alternative 006EC5D285256DE3_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <br><font size=3D2 face=3D"sans-serif">I think this is exactly the problem. There are a number of independent concepts of session involved:</font> <br> <br><font size=3D2 face=3D"sans-serif">1. The User's session with the Consu= mer =3D> rarely seems to be a problem in the discussion</font> <br><font size=3D2 face=3D"sans-serif">2. An http session between the Consu= mer and the Producer =3D> only appearance in the protocol is the requirements around handling cookies properly.</font> <br><font size=3D2 face=3D"sans-serif">3. A WSRP session (Mike calls it an entity session based on earlier terminology). This is represented by the sessionID in the protocol. <b>SOME</b> producer implementations <b>MAY</b> map this to the http session. I would encourage those implementations to only return a sessionID when needed to indicate templates or UserContext is being cached or to avoid collisions with multiple instances using the same portletHandle. <b>Other</b> implementations <b>MAY</b> map this as a finer scoped session within the http session (i.e. using groupIDs). Again, I would encourage those implementations to find means to not return a sessi= onID outside the caching and collision concerns.</font> <br> <br><font size=3D2 face=3D"sans-serif">From the protocol's point of view, t= hese three concepts of sessions are independent of each other. When Producer implementations choose to correlate them, it the job of the implementation to correctly sort out the issues introduced as the Consumer can not assume or determine that such a correlation exists. </font> <br> <br><font size=3D2 face=3D"sans-serif">From the Consumer perspective, knowl= edge that such Producer implementations will exist should drive how the InvalidC= ookie fault is handled. The Consumer should not assume the WSRP session is invali= d, but should supply those items that may have been cached so that in the case where it did become invalid, the Producer is able to create a new session without an extra roundtrip for an InvalidSession fault.</font> <br> <br><font size=3D2 face=3D"sans-serif">I'm not convinced there is a lack of clarity in the spec in this area, but there certainly are a number of rat holes one can get into if certain implementation choices are made.</font> <br><font size=3D2 face=3D"sans-serif"><br> Rich </font> <br> <br> <br> <table width=3D100%> <tr valign=3Dtop> <td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Alejandro Abdelnur &l= t;Alejandro.Abdelnur@Sun.COM></b> </font> <br><font size=3D1 face=3D"sans-serif">Sent by: Alejandro.Abdelnur@Sun.COM<= /font> <p><font size=3D1 face=3D"sans-serif">11/19/2003 01:38 PM</font> <td width=3D59%> <table width=3D100%> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div> <td valign=3Dtop><font size=3D1 face=3D"sans-serif">wsrp-interop@lists.oasi= s-open.org</font> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div> <td valign=3Dtop> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div> <td valign=3Dtop><font size=3D1 face=3D"sans-serif">Re: [wsrp-interop] on i= nitCookies and sessionID</font></table> <br> <table> <tr valign=3Dtop> <td> <td></table> <br></table> <br> <br> <br><font size=3D2><tt>The lesson learned from this one is 'Do not mistake session with <br> session' :)<br> <br> I think it would help if we clarify the spec on this.<br> <br> Thanks.<br> <br> Alejandro<br> <br> On Wednesday, November 19, 2003, at 04:52 AM, Rich Thompson wrote:<br> <br> ><br> > My take on the answers:<br> ><br> > First, overall comments: Private sessions between the end-user and <br> > particular instances of a portlet are modeled in the protocol via <br> > sessionID. It was also recognized that various systems have reasons to <br> > use a cookie to carry session information, though these types of <br> > sessions are not always unique to a portlet instance. As a result, <br> > these two tend to closely parallel each other while never being > linked.<br> ><br> > Q1. Is there any required relationship between the cookies returned by <br> > initCookie and the sessionID returned by the markup interface calls?<b= r> > A1. No, though if the CookieProtocol is perUser then they do carry the <br> > same semantics.<br> ><br> > Q2. If a call returns an InvalidCookie fault, should the consumer <br> > discard the sessionID?<br> > A2. No, the cookies are independent of the private sessionID and are <br> > not necessarily related to a session at all.<br> ><br> > Q3. If a call returns an InvalidSession fault, should the consumer <br> > call initCookie again?<br> > A3. same as A2.<br> ><br> > Sorry if the fault descriptions are confusing:<br> > - InvalidSession fault is used only when the private session has <br> > timed out and required data had been cached in the session (templates <br> > or UserContext). If the session did not contain such data or it is <br> > also available via the supplied data on the invocation, the Producer <br> > can simply create a new session and include it in the returned data <br> > structure for future invocations from the Consumer.<br> > - InvalidCookie fault is used only when the cookies established by <br> > initCookie become invalid. This signals to the Consumer the need to <br> > invoke initCookie again. Since some Producers will establish a session <br> > related to these cookies, it would be wise for the Consumer to resend <br> > templates and UserContext when reinvoking the operation that caused <br> > the InvalidCookie fault as this can avoid the next invocation <br> > returning an InvalidSession fault.<br> ><br> > Rich<br> ><br> ><br> <image.tiff><br> ><br> ><br> ><br> ><br> ><br> > One of the engineers in my group (punished with implementing WSRP) came<br> > to me with the following questions and I could not find an answer for<br> > her. I would like to know what is your opinion on this and how are you<br> > handling this scenario.<br> ><br> > Thanks<br> ><br> > Alejandro<br> ><br> > * Producer requires initCookie.<br> > * Consumer uses more than one portlet from the producer for<br> > the portal page of a user.<br> > * initCookie has been called upfront.<br> > * performBlockingInteraction and/or getMarkup have returned a sessionI= D<br> ><br> > Q1. Is there any required relationship between the cookies returned by<br> > initCookie and the sessionID returned by the markup interface calls?<b= r> ><br> > Q2. If a call returns an InvalidCookie fault, should the consumer<br> > discard the sessionID?<br> ><br> > Q3. If a call returns an InvalidSession fault, should the consumer call<br> > initCookie again?<br> ><br> > If the answer is 'no' to all the questions, then the following section= s<br> > of the spec make things more confusing:<br> ><br> > P27/L27 "If the Producer returns an InvalidSession fault message after<br> > returning a sessionID, the Consumer MUST NOT resupply that sessionID on<br> > a subsequent invocation and SHOULD reinvoke the operation that caused<= br> > the fault message without any sessionID and supply any data that may<b= r> > have been stored in the session."<br> ><br> > P44/L6 "If at any time the Producer throws a fault message<br> > (“InvalidCookie”) indicating the supplied cookies have bee= n invalidated<br> > at the Producer, then the Consumer MUST again invoke initCookie() and<br> > SHOULD reprocess the invocation that caused the fault message to be<br> > thrown and include any data that may have been stored in a session<br> > related to a cookie"<br> ><br> > P77/Table,Row=3DInvalidCookie "InvalidCookie Used only when the<b= r> > environment at the Producer has timed out AND the Producer needs the<b= r> > Consumer to invoke initCookie() again and resend data that may have<br> > been stored in sessions related to a cookie."<br> ><br> > P77/Table,Row=3DInvalidSession "Used only when a Producer session has<br> > timed out AND the Producer needs the Consumer to invoke resend data<br> > that may have been cached in the session."<br> ><br> ><br> ><br> </tt></font> <br> --=_alternative 006EC5D285256DE3_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]