[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
I see two basic changes in what Mike is proposing:
1) Change groupID from a String to an int. While this may seem like a
simplification, the most natural way to represent a group in Web terms is a
URI (subset of the string lexical space). We should have very strong
reasons if we step away from this, in fact we may want to explicitly make
this of type 'xsd:anyURI'.
2) Have the Producer specify the number of times initEnvironment() must be
called per user. This can be quite inefficient for Producers hosting many
groups. Having the Consumer determine the number of invocations based on
the unique groupIDs the End-User is interacting with sure seems like the
most efficient process.
Now that the semantics for groupID are tightening up, I think the operation
name needs to be changed to initGroup(). It is all about the Consumer
enabling the Producer specified groupings. I also think it should carry the
groupID it is targeting (in case the Producer cares) and return an <any/>
in order to remove the protocol dependence. I guess we would then have to
define where the Consumer MUST return whatever the <any/> contained ...
Gil Tayar
<Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org
lage.com> cc:
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
10/20/2002 12:57
AM
Mike,
I'm not sure how this makes things simpler than Carsten's proposal (which I
like, by the way). All you are suggesting (from what I understand) is to
replace Carsten's unnamed "application ID" to an "environment ID" that is
numeric, and adding a field in the metadata containing the number of
"environments/applications" there are in the Producer.
If that is the case, and I haven't missed anything, I would prefer
"application ID" as it is more flexible, and more XML-ish than numeric ID.
The Consumer will anyway have to have a map that groups all entities, and
keying that map to an integer vs. a string doesn't seem a big difference.
Gil
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Sat, October 19, 2002 20:11
To: wsrp-wsia@lists.oasis-open.org
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC