[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
Andre, you completely lost me. My understanding is that initEnvironment doesn't
pass or return a groupID. Its also my understanding that the groupID sent to
getMarkup/performInteraction is not the same groupID that is being proposed to
be included in the meta data, rather it is a consumer generated ID used when
initEnvironment() is not used.
Eilon, no the initEnvironment() wouldn't have to be called as frequently as
you suggest. I expect most JSR 168 containers to do an initial check to see if
the passed session is still valid before communicating to a portlet. If its
invalid, it throws the defined exception which causes the consumer to recall
initEnvironment() and thus reestablishing the session before retrying.
-Mike-
Andre Kramer wrote:
> 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>
>
> ----------------------------------------------------------------
> 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