wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] initCookie
- From: Rich Thompson <richt2@us.ibm.com>
- To: WSRP <wsrp@lists.oasis-open.org>
- Date: Thu, 19 Jun 2003 13:25:49 -0400
It sounds like another way to express
what you are saying is "Why use an extra operation rather than just
requiring the Consumer to wait for the return of the first getMarkup()
before invoking the others in parallel?"
If so, I remember discussing this as
an option, but don't remember why we decided on the separate operation.
Does anyone else remember?
Rich Thompson
| Subbu Allamaraju <subbu@bea.com>
06/19/2003 01:13 PM
|
To:
WSRP <wsrp@lists.oasis-open.org>
cc:
Subject:
Re: [wsrp] initCookie |
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]