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?


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>



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


Powered by eList eXpress LLC