Re: [wsrp] initCookie

[Rich Thompson <richt2@us.ibm.com>]

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.

The solution allows this type of Producer
to request the Consumer to invoke initCookie before any other request and
then supply any returned cookie(s) on subsequent requests. This moves the
synchronization point out to the Consumer.

The InvalidCookie fault just allows
the Producer to inform the Consumer that it needs to discard the previous
cookie(s) and restart.

The InvalidSession fault processing
is just a mechanism for clean recovery of Consumer state in the portlet's
session rather than exposing this loss to the end-user. End-User state
will still be lost.

Rich Thompson

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