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

[Eilon Reshef <eilon.reshef@webcollage.com>]

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>