[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
The assumption is that something on the producer detects that the http
session expired (and has possibly been recreated automatically), throwing a
soap fault to signal that a (new) call to iniEnvironment() is required [I
also prefer to name it initGroup()]. Now, I would still say that including
the groupID, that initXXX returns, on each performInteraction() or
getMarkup() call help with exactly this kind of session expiry detection.
[initGroup() puts the groupID in the session object. performInteraction()
and getMarkup() check that the session contains the right group id. So the
'redundancy' can help detect expired sessions and consumer problems in
following transport cookie requirements.]
regards,
Andre
-----Original Message-----
From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
Sent: 22 October 2002 22:01
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
Mike,
Thanks for the elaborate explanation.
Wouldn't this also imply that the Consumer needs to call initEnvironment
on every page, to handle cases where the session expires? I.e., a JSR168
Producer will renew the session automatically, and this also needs to be
serialized?
Eilon
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Tuesday, October 22, 2002 3:35 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
Eilon,
I also remember that at the F2F we decided to discourage the
practice of using shared data. In doing so we decided that an ID
corresponding to a shared session wouldn't be defined/carried in our
protocol. Instead, I recall we said that portlets needing to do such a
thing wouldn't have to attach/encode the shared session ID in the entity
session ID. To deal with concurrency issues [calls handled concurrently
from different users and calls handled concurrently for the same user],
groupID was added to the getMarkup/performInteraction calls. Used here,
groupID is consumer defined name for the potential shared session.
After the F2F, we learned that the above mechanism wouldn't support
JSR 168. There were two problems: a) In the JSR 168 world shared
sessions are encoded in an http cookie. b) There was no convenient,
safe way to create such a cookie in a concurrent, load balanced
environment.
My understanding is that when we added initEnvironment() we didn't
[intend to] remove the "encode shared sessions in an entity session
mechanism". The .7 Draft still passed this consumer generated ID to
getMarkup, etc. What seems to have been under discussion here is
whether the groupId that was passed to initEnvironment() was needed. As
initEnvironment() itself signified a group it appeared we could remove
it. However, Carsten then came up with a usage that though not required
would make implementing a producer [in the usage scenario] easier.
Namely have a producer meta-data defined groupId that allows the
consumer to understand and manage the fact that this producer requires
more than 1
initEnvironment() [per user]. So in the end there are two concepts of
groupId in our spec [if we adopt Carsten's proposal]. The groupID in
meta data that controls the number of times initEnvironment is called
for a given user and the groupID that is sent to
getMarkup/performInteraction that defines a shared session context.
This later is still a consumer generated ID though if we add the former
we will likely constrain its semantics. I.e. the consumer groupID can't
cross producer groupID boundaries.
As for your suggestion about removing initEnvironment and restricting
the semantics of sharing so that sharing can't begin until a
performInteraction is called -- this unfortunately won't work for JSR
168. JSR 168 allows the shared session to come into existence at any
time -- hence why we invented initEnvironment(). We could however
consider your suggestion for our "official" shared session mechanism --
i.e. only pass the consumer groupID to performInteraction -- and
mandating that if shared sessions are to be used they can/must only be
started in a performInteraction.
-Mike-
Eilon Reshef wrote:
> Carsten, Mike, Andre, Rich, and other participants in the groupID
> discussion:
>
> I would like to bring up a question regarding groupID and
> initEnvironment. It's actually mainly regarding initEnvironment, but
> the two are tied together, it seems.
>
> Here goes--
>
> To the best of my understanding, the purpose of
> initEnvironment/groupID is to support a situation where two or more
> portlets need to share a session in order to share transient data. In
> the F2F, this was discouraged as a practice, but yet we would like to
> support it mainly for legacy apps and for JSR168 portlets that use
> this practice.
>
> It is my understanding that the scenario is that portlet A stores some
> data in the session, which portlet B picks up and uses. One example
> brought up was two e-mail portlets: Inbox and MessageText, which are
> synchronized (the user clicks on a mail message, and the MessageText
> portlet updates).
>
> I completely understand the scenario in the "performInteraction" case.
> The user clicks on a different e-mail item in the Inbox portlet, the
> Inbox portlet handles the performInteraction call, stores the id of
> the e-mail message in the session, and when the getMarkup call is
> issued, the MessageText portlet knows which e-mail message to display.
>
> What I fail to see is a scenario where two portlets share information
> *even before* the first interaction has happened. Since portlets
> cannot dictate to the Consumer the order in which they should be
> rendered, then it's very hard for a portlet assume that data from the
> other portlet will be available. (Transient data, that is. Persistent
> data is not an issue anyway and doesn't need to go through the
> session.)
>
> If indeed data sharing is applicable only after interaction, wouldn't
> it be reasonable for us to assume/dictate that portlets that need to
> share data would create the session upon first interaction. If that's
> the practice we support, and since performInteraction happens
> sequentially anyway, wouldn't that allow us to eliminate the need for
> initEnvironment altogether?
>
> Thus, the scenario would be (temporarily ignoring the unification of
> entities and sessions):
> - Portlets that return a new session in the a getMarkup() cannot
> rely on that session to be passed to other portlets in the same page
> (behavior is undefined).
> - This is true also when a session is being invalidated for timeout
> reasons
> (Did we ever agree on the scenario there?)
> - Portlets that return a new session in the performInteraction() call
> may
> always rely on that session to be passed to all relevant portlets
> when the
> page is rendered.
>
> The groupID question is still open even under this scenario, namely:
> the Consumer may be required to transfer the new session to all
> portlets within the Producer or only to a subset of the portlets.
>
> However, my question is whether this assumption allows us to eliminate
> the initEnvironment() call?
>
> Eilon
>
> -----Original Message-----
> From: Carsten Leue [mailto:CLEUE@de.ibm.com]
> Sent: Monday, October 21, 2002 7:28 AM
> To: wsrp-wsia@lists.oasis-open.org
> Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
>
> Mike -
>
> if I understood your proposal correctly you agree in princple with the
> concept of having metadata that is telling the consumer how to group
> entities but propose a different way to do it. The basic
> simplification seems to be that the producer is enumerates all of its
> groups (i.e. applications), so the groupID (--> environmentID) would
> be much more limited in range than as if it was a GUID. What is not
> clear to me is how a producer could safely tell how many applications
> it hosts. This number may change when new applications are deleted or
> added. Whouln't it be much simpler to have a globally unique identifer
> as the groupID without exposing mutable producer internals?
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
>
>
> Michael Freedman
>
> <Michael.Freedman
>
> @oracle.com>
> To
> wsrp-wsia@lists.oasis-open.org
>
> 10/19/2002 08:11
> cc
> PM
>
>
> Subject
> Re: [wsrp-wsia] Issues #6 - Is
>
> groupID required?
>
>
>
>
>
>
>
>
>
>
>
>
>
> Carsten,
> This looks good, but I think we can [and should] make it a little
> simpler. Basically, as groupID is no longer carried over the wire we
> need not concern ourselves with arbitrary group names. I suggest we
> do the
> following:
> 1) We change the doInitEnvironment field in ServiceDescription to
> something like numInitEnvironments. numInitEnvironment would be an
> int. A value of 0 would mean initEnvironment should not be called. A
> number
> > 0 indicates how many initEnvironments the producer requires.
> 2) We change the groupID field in EntityDescription to something
> like environmentID. environmentID would be an int. Its value would be
> between 1 and numInitEnvironment inclusive. If numInitEnvironment is
> 0 or 1 the environmentID field is ignored by the consumer. [When
> numInitEnvironment is 0 this field can be ignored because there are no
> environments. When numInitEnvironment is 1 this field can be ignored
> because all entities are in the 1 enviornment.] If > 1, environmentID
> indicates the environmental context that should be used when
> interacting with this entity. Values outside the range [or missing]
> signify invalid entity descriptions. Consumers must not activate/use
> such entities.
>
> This simplification makes consumer management/lookup simpler and more
> efficient and seemingly loses nothing on the producer side.
> -Mike-
>
> Carsten Leue wrote:
> Hi all.
>
> As discussed on Thurday's call here is a writeup of the proposal
> we
> discussed.
>
> procedure:
> 1. the producer tells via metadata what entities belong to an
> application.
> The producer assigns an ID (or name) for each such group. This
> name
> should
> ideally be globally unique.
> 2. the consumer MUST respect the metadata grouping information.
It
> MUST
> call initEnvironment for each user session prior to making a
> call to
> any
> entity that belongs to a group.
> 3. it would not be required to transfer the grouping-metadata at
> all
> across
> the wire, so we could remove groupID (see the disadvantages
> section)
> 4. the consumer must respect cookies and headers in the HTTP
> case
>
> advantages:
> - no explicit groupID mechanism that pollutes the protocol
> - compliance with JSR168
>
> disadvantes:
> - we lose our per-instance grouping concept
> - functionality depends on metadata-awareness
>
> comments:
> to 1: in the JSR168 case the producer will choose the
> application ID
> as the
> groupID
> to 2: calling initEnvironment on a per-group basis provides a
> simple
> (yet
> protocol dependent) mechanism for the producer to support
multiple
> JSR 168
> applications. As each application requires an HTTP session and
the
> JSR168
> producer respects (1), the call to initEnvironment establishes
> such
> an HTTP
> session. Together with (4), ensuring that the session will be
> kept,
> the
> producer can reuse this session between the consumer and the
> producer
>
> directly as the HTTP session required by the JSR. No
> re-implementation of
> session management on the producer would be required.
> to 3: after the session has been established the groupID does
> not to
> travel
> over the wire as the HTTP together with the entityHandle implies
> the
> appropriate grouping on the producer. This implies that the
> consumer
> side
> grouping equals exactly the producer side grouping. (1),(2) and
> (4)
> ensure
> that.
>
> Comments?
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC