Re: [wsrp] initCookie

[Subbu Allamaraju <subbu@bea.com>]

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