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

[Michael Freedman <Michael.Freedman@oracle.com>]

I am still not getting it.  You suggest a situation where it is difficult to
sequentially number all the groups -- but your situation implies much more
dynamics then I thought we allowed.  What is the meaning of a consumer
calling getServiceDescription() on the producer?  Doesn't this call return
all the meta data for all the entities managed by this producer?  Isn't the
consumer allowed to consider this information the whole truth until it
decides to call getServiceDescription() again?  If so, doesn't this imply
the producer can answer the how many groups and which entities fall into
which ordinal?  I am not seeing the complication you suggest I am causing.
    -Mike-

Eilon Reshef wrote:

> Mike,
>
> It makes sense to provide special care for the two options you noted:
> - "0" grouping/sharing/initialization (no shared sessions, should
> probably be a common deployment method even for JSR168 producers)
> - "1" (one application, should be a common deployment practice for
> JSR168 producers
>
> However, I think your assumption is that the entire configuration of the
> Producer is loaded in initialization time (e.g., because it has a single
> deployment descriptor).
>
> I believe in any other case (dynamic loading, or complex deployment
> environment), it would probably be harder for the Producer to correctly
> manufacture unique serial numbers than for the Producer user to
> manufacture unique global ids.
>
> As one example (although admittedly not an important one from a business
> perspective), consider an application-level WSRP proxy that proxies
> multiple WSRP Producers. It would be extremely difficult for such an
> animal to sequentially number all the "groups" for all the different
> Producers it proxies.
>
> Eilon
>
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Tuesday, October 22, 2002 4:14 PM
> To: wsrp-wsia@lists.oasis-open.org
> Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
>
> Carsten,
> From reading this response and another by Rich, I find myself worried I
> don't fully understand your proposed mechanism.  You write:
>     "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."
>
> Rich writes:
> "Have the Producer specify the number of times initEnvironment() must be
> called per user. This can be quite inefficient for Producers hosting
> many groups."
>
> These comments seem to imply more dynamics then I was expecting.  Isn't
> meta-data acquisition under the control of the consumer?  Aren't
> consumer's allowed to consider such acquisition a snapshot of the
> configuration?  If so then how can a producer not safely tell how many
> applications it hosts?  When it answers getServiceDescription() it has
> to know for that given point in time, right?  And the consumer can cache
> this for as long as it wants, right?
>
> On the flip side, I suggest the numbering scheme with the following
> reasons:
>     a) I want to make it extremely easy for a consumer to determine that
> only 0 or 1 initEnvironment need be called.  I.e. if its 0 or 1 the
> consumer doesn't have to do any lookups.  My reason for this is a belief
> the protocol should prefer the case where the producer is the grouping
> mechanism.  The situation we are considering adding is a special case in
> that it need not exist for a producer [with such semantics] to be
> implemented.  Nor for some of us will it be a common case.
>     b) I want to isolate the consumer from name management, particularly
> name changes.  Within a given conversation why does the consumer care
> what a name of a group is?  It merely needs to now how many groups need
> to exist and how to partition the entities.  Between
> getServiceDescription calls this name can't change on the producer side
> -- this tends to imply the producer will have to manufacture a name --
> I.e. it can't use the JSR 168 portlet application name or location
> because this may change.  By specifying that these names are numbers we
> make it easy for the producer, make sure the producer doesn't do the
> wrong thing [use a name that changes], and make it easy for a consumer
> [to store environments/cookies at a producer level] and do fast indexed
> lookups.
>     -Mike-
>
> Carsten Leue wrote:
>
> > 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>