[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [wsrp] initEnvironment and groupID - my finalthoughtsbefore we vote
My understanding is that we have proposals on the table where:
1) The Producer does not need initEnvironment() and is able to host/manage
an environment for multiple portlet applications on a clustered server.
2) The Producer relies on initEnvironment() for establishing a shared
session for the portlet application.
If we insist on the first type of implementation, then the need for
initEnvironment() goes away. If we want to support the second (keep
initEnvironment()) and choose to drop groupID, then the shared environment
becomes Producer-wide and for JSR168 this means a Producer per portlet
application. If we keep both initEnvironment() and groupID, then the
semantics of what it means for the Consumer to specify a groupID need to be
clarified significantly.
I am certainly open to clarification on the above points.
My final point in the previous posting was from the point of view of
cleanliness of the protocol. I would prefer to either not have any concept
in the protocol of Producer-mediated data sharing OR have the protocol
provide the means for the Consumer to explicitly scope that data sharing.
Anything in the middle involves the Consumer being required to do things
without any control on what the implications of those things are.
Michael Freedman
<Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org
oracle.com> cc:
Subject: Re: [wsrp-wsia] [wsrp] initEnvironment and groupID - my
10/15/2002 01:41 final thoughtsbefore we vote
PM
Rich,
I believe "initEnvironment() satisfies/supports JSR 168" whether of not
there is one producer per jsr portlet
application. The issue of multiple applications per producer is one of
implementability to JSR and not something
that pertains to WSRP and the groupID issue. If such a thing is
implementable, and I explain a possible solution, I
still expect that the JSR producer will be able to easily dispatch [entity]
calls to the appropriate portlet
applications because it knows which entities belong to which applications.
Hence I don't see the need for groupID in
this situation. Can you explain why a groupID is needed here? Also, can
you elaborate on the "preferredGroupID"
model you begin to describe. I don't understand the scope it defines as
neither the current spec nor your
description here ties groupID to a user.
Finally, you state "If we do not introduce Consumer scoping of the data
sharing, then I again
question what the Producer-mediated data sharing concept is doing in the
protocol." What exactly do you mean by
this? Do you mean for a consumer to be able to define [maybe within
bounds] specific new scopes? If so why don't
you consider this a vendor extension? And if its an extension, why should
we treat it specially in the protocol vs.
carrying it via our extension mechanism.
-Mike-
Rich Thompson wrote:
> You state that "initEnvironment() satisfies/supports JSR 168" ... from
our
> recent discussion of this topic, this is true only if there is a Producer
> per portlet application. In considering whether this will be a reasonable
> restriction, I would like to see some estimates of the number of portlet
> applications in a typical portal deployment. I wonder whether this would
be
> an acceptable restriction to spec implementations/deployments. It has
> significant impacts on areas such as registration. I would also note that
> there have been 2 proposed means for the Producer to achieve the
necessary
> function without initEnvironment().
>
> My personal preference is that if we introduce the concept of
> Producer-mediated sharing into the protocol at all, it should include
> Consumer specified scoping on that sharing. The possibility I have heard
> proposed for this is:
>
> - The entity metadata includes a "preferredGroupID". For JSR168, this
maps
> directly to the portlet application name.
> - The protocol includes groupID in the current manner with the semantics
> tightened to require the Producer to scope any data sharing by the
supplied
> groupID. The Producer would still be free to further scope the data
sharing
> according to its policies.
>
> This combination allows Producers to scope data sharing more tightly than
> the Consumer specifies, but does not allow crossing the Consumer
specified
> boundary (supports the often mentioned a1/b1 & a2/b2 on the same page use
> case).
>
> If we do not introduce Consumer scoping of the data sharing, then I again
> question what the Producer-mediated data sharing concept is doing in the
> protocol.
>
>
> Michael Freedman
> <Michael.Freedman@ To:
wsrp-wsia@lists.oasis-open.org
> oracle.com> cc:
> Subject: Re: [wsrp-wsia]
[wsrp] initEnvironment and groupID - my
> 10/10/2002 02:12 final thoughts before we
vote
> PM
>
>
>
> Well, I think Andre may be technically correct -- in that the servlet
> architecture allows one to place a filter in front of the a [set of]
> applications and this filter could implement/expose its own notion of
> HttpSession for the application on top of/within the HttpSession
> established
> between the consumer and the producer. It would be an extraordinary
> implementation. Without writing such special code to mimic the true
> servlet
> session, Carsten you are right that one ends up with a single JSR
> application
> per producer. However, even in Andre's situation there is no need for a
> group
> ID. The producer has the information available to it do the proper
> filtering/partitioning without any consumer management.
>
> In the end Carsten, I think your e-mail lays out the discussion very
well.
> We
> know that initEnvironment() satisfies/supports JSR 168. So the question
> before
> us is what level of support do we want for non-JSR environments?
>
> There are only three choices:
> 1) No [additional] sharing is defined by the protocol. Any
[additional]
> sharing information has to be carried entirely via the extension
mechanism.
> 2) The protocol defines very specific consumer semantics for at least
one
> form of sharing. Vendors can choose to further extend this semantic via
> the
> extension mechanism.
> 3) The protocol allows a producer to express very specific producer
> semantics
> for at least one form of sharing. Vendors can choose to further extend
> this
> semtanic via the extension mechanism.
>
> Currently, the specification tries to do 2. It defines a "groupID" to
> carry a
> consumers notion of how portlets are grouped. It further states.
"Section
> 7.1.1 (page 31, line 20): "Since Consumers will not know what entities
> could
> benefit from any Producer mediated data sharing, they SHOULD place all
> entities
> from a Producer within a single group until a reason is identified for
> specifying a separate groupID." This definition has two problems. It
> neither
> defines a specific semantic (it uses the term SHOULD) nor is the semantic
> useful.
>
> I suggest that our default choice should be (1). Sharing is not defined
> and
> therefore must be added as a vendor extension. For those of you that
would
> like to see sharing in v1, whether of the form (2) or (3), I think your
> burden
> is to provide us with a clearly defined semantic and to get consensus
from
> all
> of us that all consumers will/should support this semantic [in v1].
Though
> I
> have heard arguments for keeping sharing I haven't yet seen a proposal
that
> defines its semantics clearly. Does anyone want to make a proposal?
>
> -Mike-
>
> ----------------------------------------------------------------
> 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