[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
Rich,
I don't think we should rename initEnvironment() to initGroup(). For me initEnvironment() is still about
initializing the underlying transport environment. The grouping we are defining is a particular
specialization that indicates that a producer needs to have entities segmented into different environments.
This specialization is only being added to make it convienent and easy for a JSR 168/WSRP container to be
implemented when that container is managing multiple JSR 168 portlet applications [ or anything else that
needs multiple cookies per producer]. I.e. there is no technical reason for adding this support -- the above
grouping is implementable without us doing anything -- we just don't want to make the producer to have to do
any work. Though in some companies environments these types of producers may be common there will be many
such environments where they are not. For me, initEnvironment() remains the best name.
-Mike-
Rich Thompson wrote:
> 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>
>
> ----------------------------------------------------------------
> 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