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?


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>



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


Powered by eList eXpress LLC