OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] initCookie


True for creating the cookie for the first time but not true for 
reestablishing the cookie after it has timed out.
   -Mike-

Subbu Allamaraju wrote:

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