[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]