[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] initCookie
In the scenario being discussed, the producer does not have to anticipate how the consumer is implemented. If initCookie is called and if the producer has already set a cookie for that consumer (during a usual markup operation), the producer would simply return. Else, it would create a new cookie. In fact, you brought the point I was trying to make. This is a consumer's problem and not the producer's. Subbu Michael Freedman wrote: > By requiring it the producer doesn't have to anticipate how the consumer > is implemented. I.e. as a requirement the producer codes itself in a > single way -- if its not a requirement the producer must code itself to > establish/reestablish cookies in both mechanisms. -Mike- > > Subbu Allamaraju wrote: > >>> The particular scenario this area of the spec was designed to solve is: >>> A load-balanced Producer where: >>> - a cookie set on the first request is used for routing on all >>> subsequent requests >>> - the Producer does not want to do the synchronization >>> necessary to ensure that multiple parallel requests targeting >>> portlets that are within one portlet group (i.e. all will use a >>> single shared session on the Producer) all get routed to the same >>> node in the cluster such that the shared session can be managed >>> reasonably. >> >> >> >> Yes. With such a producer, if a consumer is making concurrent >> requests, it will have to invoke initCookie to get new cookies. >> >> But my question is why should it be *required* for the consumer to >> invoke this operation? The consumer knows the situations during which >> it should be careful about session cookies. For instance, if a >> consumer is making requests sequentially, the producer can establish >> the session automatically. >> >> Regards, >> >> Subbu >> >>> >>> >>> *Subbu Allamaraju <subbu@bea.com>* >>> >>> 06/19/2003 11:57 AM >>> >>> To: WSRP <wsrp@lists.oasis-open.org> >>> cc: Subject: Re: [wsrp] initCookie >>> >>> >>> >>> >>> I'm not sure if it does. I'm probably dense on this, but I'm not >>> convinced the wording helps justify this operation. Your suggested >>> wording implies that this is a producer's requirement, but it seems to >>> be a consumer's problem. IMO, the current wording places >>> responsibilities inconsistently (more below). >>> >>> There are two problems here: >>> >>> (a) Consumer making multiple simulataneous requests. >>> >>> (b) Producer requiring initCookie before any markup request is made. >>> >>> The first problem is analogous to an HTTP client making multiple >>> requests (say in a frameset). In this case, the requests won't be able >>> to join in the same session the first time, and this will be corrected >>> in subsequent requests (if cookies are used for session tracking). In >>> WSRP, this is strictly a consumer's problem. >>> >>> On the producer side, the producer can always establish/reestablish >>> sessions as required and set the cookie (if it uses cookies) in the >>> response. There is no need for a separate initCookie operation for this >>> purpose. This is an unnecessary burden on the producer. >>> >>> In order to resolve the current inconsistency, I suggest that the spec >>> reflect the following (and the changes below): >>> >>> (a) Rename requiresInitCookie to supportsInitCookie. >>> >>> (b) If a consumer is making concurrent requests (or for whatever >>> reasons), it may invoke the initCookie (if supportsInitCookie is true) >>> before making concurrent markup requests. >>> >>> (c) The producer may reestablish the session transperantly if it was >>> found invalid during the course of a request. Right now it throws >>> InvalidSession fault forcing the consumer to drop everything, call >>> initCookie and reinvoke the operation. IMO, this is quite unnecessary. >>> >>> (d) If the producer stores templates/user profile in the session and it >>> reestablishes the session during a request, the producer would throw a >>> MissingParameters fault (or some kind of a new fault >>> MissingParametersStoredInSession fault), and the consumer could reinvoke >>> the operation with the missing parameters. In this case there is no need >>> to invoke to initCookie operation. >>> >>> (e) If the consumer is making concurrent requests, it may get >>> MissingParametersStoredInSession fault for all requests for that >>> producer. At this point, consumer may invoke initCookie and retry. >>> >>> IBO, unless I'm missing something else, these changes would shift the >>> responsiblities to where they belong. >>> >>> Regards, >>> >>> Subbu >>> >>> Rich Thompson wrote: >>> > >>> > Would it help if the first sentence of section 3.12 had the following >>> > appended? >>> > ", especially in the context of potentially handling multiple >>> > simultaneous invocations from a Consumer." >>> > >>> > Rich Thompson >>> > >>> > >>> > *Subbu Allamaraju <subbu@bea.com>* >>> > >>> > 06/19/2003 08:52 AM >>> > >>> > > To: WSRP >>> <wsrp@lists.oasis-open.org> >>> > cc: > Subject: [wsrp] initCookie >>> > >>> > >>> > >>> > >>> > >>> > I've a few questions on the reason behind the initCookie operation >>> and >>> > the way it is specified. >>> > >>> > Per the spec, this operation is supposed to let the consumer *assist* >>> > the producer in establishing certain cookies that the producer *may* >>> > require for managing a load-balancing environment. >>> > >>> > However this reasoning is somewhat vague. In particular it does not >>> > explain why WSRP has this special requirement when most HTTP-based >>> apps >>> > don't require such a process. In a sesne WSRP is going beyond HTTP >>> and >>> > Cookie RFCs in requiring an extra operation to initialize a >>> producer's >>> > environment. >>> > >>> > More importantly, the spec does not explain what prevents a producer >>> > from establishing the same cookies upon the *first request* from the >>> > consumer in a transperant fashion, and why it needs consumer's help. >>> > >>> > I'm looking for a clarification on this operation. >>> > >>> > Regards, >>> > >>> > Subbu >>> > >>> > >>> > You may leave a Technical Committee at any time by visiting >>> > >>> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php >>> >>> > >>> > >>> >>> >>> >>> You may leave a Technical Committee at any time by visiting >>> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php >>> >>> >>> >> >> >> >> You may leave a Technical Committee at any time by visiting >> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php >> >> > > > > You may leave a Technical Committee at any time by visiting > http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]