[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
I guess I am missing something. I don't understand how an entityHandle gives the necessary information for a
producer to handle initialization issues. How does a producer distinguish between 2 different users accessing
the same entity? I thought the original groupId [passed to performInteraction/getmarkup] allowed the consumer
to express which [concurrent] invocations where in its concept of a session. If we want to support this type
of initialization don't we still need this?
As for passing groupID to initEnviroment() I really prefer we don't do this. Unlike initilaization grouping,
this type of grouping is clearly not needed in our specification -- it is being added as a convenience and we
would be served much better by not exposing it in the protocol. In particular I want nothing to do with
groupID when all the entities of a producer are in the same logical group.
-Mike-
Rich Thompson wrote:
> My understanding (reflected in v0.8 :}) is that groupID is not sent on
> getMarkup/performInteraction invocations at all. For Producers using
> initEnvironment, it has already been used there. For those handling the
> initialization issues themselves, the necessary information is available
> through the entityHandle reference.
>
> I have kept groupID on the initEnvironment invocation for v0.8 (though
> required it to be one the Producer specified) as this keeps the semantics
> of the invocation clearer and reduces the sophistication required of the
> Producer.
>
>
> Michael Freedman
> <Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org
> oracle.com> cc:
> Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
> 10/23/2002 01:07
> PM
>
>
>
> 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>
>
> ----------------------------------------------------------------
> 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