OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?


I thought our original plan was to support entity session sharing without requiring use of a transport
mechanism.  I thought the transport mechanism and associated solution was tacked onto the original plan to
solve the JSR case.  I don't recall any discussion where we said we should remove the original plan in
preference for one that relied on using transport level mechanisms.  I.e. why isn't there a (c) in your
proposal that is essentially (b) but without reliance on a transport mechanism?  In fact I thought we
restricted the use of transport mechanisms to initEnvironment only -- i.e. it wasn't safe to
introduce/initialize transport level data outside an initEnvironment().

Regardless of whether we have both (b) and (c), (c) only, or (b) only, I still don't understand how this
scenario works.  I don't understand how a producer distinguishes between 2 concurrent requests for the same
user of an entity [as defined by the consumer] and 2 concurrent requests where each is for a different user of
an entity [as defined by the consumer].  How does it know in the first case to only create a single shared
session while in the second case it needs to create two distinct session?  I had thought that this was the
purpose of the groupID passed to getMarkup and performInteraction in the original version of the plan.

Can you expand on your view of how (b) works without such information?
     -Mike-

Rich Thompson wrote:

> It certainly sounds like we have different viewpoints on what is the
> proposal on the table. Let me back up and try to clearly state what I
> thought it was.
>
> 1) All concept of the Consumer scoping Producer-mediated sharing is removed
> from the protocol.
> 2) Producers fall into 2 camps:
>      a) Those that request Consumer assistance in initializing their
> sharing; namely initEnvironment MUST be called per unique groupID the
> Consumer will use per user (where per user is the Consumer definition of
> user of the entity). The items returned from initEnvironment (currently
> envisioned as transport issues only) MUST be supplied on subsequent
> invocations on behalf of the user that target any entity sharing that
> groupID.
>     b) Those that manage the concurrency issues of establishing
> data-sharing areas on their own. For these, any transport issues may be set
> on any invocation and the Consumer MUST return those settings on future
> invocations for this user which target the same entity. GroupID is never
> needed in this case because the Producer already knows what grouping the
> entity belongs in.
>
> From this I deduce that groupID is only needed in the entity metadata for
> those Producers that require the use of initEnvironment(). Any other use is
> gratuitous (i.e. for clarity).
>
> Where does your viewpoint differ?
>
>
>                       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:51
>                       PM
>
>
>
> 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>
>
> ----------------------------------------------------------------
> 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