Re: [wsrp] initCookie

[Michael Freedman <Michael.Freedman@oracle.com>]

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 
>
>