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

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

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>