[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
I believe that policy should be separated from mechanism, if possible, but
for common mechanism to be supported well by the protocol. This is why the
producer advertises a "preferredGroupID", leaving the consumer free to
prefer-not-to (a possibility Rich describes by example in (2) below).
Classes of users of the protocol (interoperable consumers and producers) may
then select to follow a common policy. A sensible one (for strict
application scopes at the producer) would be to only allow the consumer to
further specify sub-groupings on the preferredGroupIds (and to only accept
consumers following the producer's strict policy). Selecting the policy is,
in my opinion, a kind of vendor extension, but likely common to classes of
vendors (which could be added as policy rule appendixes, e.g. for JSR168).
The mechanism really needs groupID to be communicated *both* in
initEnvironment() [iff initEnvironment() required] and in all scoped
operations. Otherwise, we will be limited to one and only one policy (or
worse none, e.g. if groupID is controlled by the end user or groupID is
unused or vendor-private).
In this view, both
no-group-ID&no-user-load-balancing/producer-is-single-application and
consumer-may-only-subdivide-producer-application-groups are candidates for a
grouping policy appendix (but I still think the latter makes the former, at
best, redundant).
-- Andre
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 16 October 2002 16:46
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
Thanks for the example. I think it illustrates my point well. You ask:
"Is there value to having the
Consumer isolate the 2 instances of P1 from
each other?". And you answer it yes. This surprised me. My answer is "No,
unless the producer sees this as a
specific vendor extension." I.e. though there is value to a producer in
having portlet entities of the same
type isolated from each other so namespacing isn't needed to avoid
collisions, we haven't defined or proposed
any specific semantic in the specification that guarantees this. Without
this an entity must assume a
consumer may group multiple instances together in the same group. The only
way it receives the value you
illustrate is if it recognizes the specific vendor portal doing the grouping
and understands that this
specific vendor makes such a guarantee. In this case it could choose to
adjust its implementation to behave
with the benefits you imply. However, this is exactly the defintion/intent
of vendor extensions hence my
argument that groupID be treated there.
-Mike-
Rich Thompson wrote:
> Lets consider a concrete example:
> Presume a Producer (JSR168 semantics) exposes the following entities:
>
> PreferredGroupID EntityName
> Group1 P1
> Group1 P2
> Group1 P3
> Group2 P4
> Group2 P5
>
> The Consumer assigns the following grouping:
>
> groupID Entity
> G1 P1
> G1 P2
> G1 P5
> G2 P1 (2nd instance on page)
> G2 P2 (2nd instance on page)
> G3 P3
>
> Key questions:
> 1) Is there value to having the Consumer isolate the 2 instances of P1
from
> each other? I think the answer is yes.
> 2) Should the Consumer be allowed to place P5 in G1 despite this going
> against the "preference" of the Producer? I can go either way on this. If
> it is allowed, then Producers where data sharing semantics would not allow
> these to share data (i.e. JSR168) should define their own sharing scopes
> within the Consumer's specification to enforce their policies. Producers
> without such policies could pass through the Consumer's sharing
> specifications. I can also argue that the Producer specification should be
> taken as more than a hint and therefore it is invalid for the consumer to
> include P5 in G1.
> 3) Should the Consumer be allowed to isolate entities the Producer has
> grouped? In other words, should the Consumer be forced to place P3 in one
> of the other groups? I think there is always value in allowing such
partial
> groups and would prefer the Consumer have this flexibility.
>
> I hope this helps, but since I wasn't the originator of this proposal I
> also hope I haven't gone way off base on what was proposed.
>
>
> Michael Freedman
> <Michael.Freedman@ To:
wsrp-wsia@lists.oasis-open.org
> oracle.com> cc:
> Subject: Re: [wsrp-wsia]
Issues #6 - Is groupID required?
> 10/15/2002 03:45
> PM
>
>
>
> Rich,
> On proposal (1), you state it "requires that the Producer mediated
> sharing
> is scoped to all of the entities it exposes". I think it might be fairer
> to
> state: "In our protocol, Producer-mediated sharing is scoped to all of
the
> entities it exposes. Producers needing finer grained sharing are free to
> implement this function transparently to the consumer within this scope".
> I.e. The function defined in proposal (2), is easily implemented entirely
> within the producer without exposing any notion of groupID.
> As for proposal (2), that do we think the value of tighter "grouping"
> is? I
> recall two have been discussed: (1) used to isolate two instances of a
> portlet
> from each other -- i.e. a portlet doesn't have to worry about colliding
> with
> other instances of itself in this shared space (2) a way to pass/manage
> sharing
> between a set of portlets.
> I don't see how either of these is satisfied by your second proposal.
> If I
> understand it correctly, the preferredGroupID is at the entity [type]
level
> not
> the per entity level. I.e. all consumer configured entities derived from
> this
> proffered entity get the same preferredGroupID. If this is the case then
> value
> (1) cited above isn't achieved. As value (2) is just an extension of (1)
> --
> i.e. the use case is meant to group a specific set of entities -- not all
> consumer configured entities + its prooffered entity, it also isn't
> achieved.
> Can you explain the usage case proposal (2) addresses?
> -Mike-
>
> Rich Thompson wrote:
>
> > We need to reach a decision on this ... basically everyone agrees that
> the
> > semantics in draft v0.7 need clarification for this to be useful. The 2
> > proposals we have had put forward are:
> >
> > 1) Remove groupID from the protocol as we have no specific semantics for
> > it.
> > - It has been noted that this, combined with keeping
> initEnvironment
> > (), requires that the Producer-mediated sharing is scoped to all of the
> > entities it exposes.
> >
> > 2) Add entity metadata for "preferredGroupID" - Allows Producers to
> expose
> > the effect of their data sharing policies.
> > Add semantics to groupID that it specifies Consumer-level scoping on
> > the Producer-mediated data sharing. This allows the Producer to define
> > finer levels of data-sharing scopes, but does not allow those to cross
> the
> > Consumer-specified scoping. This would be added as a MUST restriction on
> > the Producer.
> >
> > I have tried to represent these proposals objectively (sorry if I failed
> to
> > do so). In order to reach a decision, we need explicit pro/con
statements
> > for these proposals and I would ask their proponents to post them ASAP.
> >
> > ----------------------------------------------------------------
> > 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>
----------------------------------------------------------------
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