[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-interfaces] Re: [wsrp] Soliciting a Discussion around TransientEntities
I want to be able to have two instances of a portlet in a given portal structure that share the persistent data but have distinct runtime state.
I.e. from a customization standpoint -- changing the settings in either portlet affects both, however from a runtime standpoint each portlet can be
in a completely different runtime state.
-Mike-
Carsten Leue wrote:
> Mike -
>
> could you please explain to me why the persistent entity handle could not
> be used as this key?
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
> |---------+----------------------------->
> | | Michael Freedman |
> | | <Michael.Freedman@|
> | | oracle.com> |
> | | |
> | | 06/11/2002 11:43 |
> | | PM |
> | | Please respond to |
> | | Michael Freedman |
> | | |
> |---------+----------------------------->
> >---------------------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: wsia@lists.oasis-open, wsrp@lists.oasis-open.org |
> | cc: |
> | Subject: Re: [wsrp] Soliciting a Discussion around Transient Entities |
> | |
> | |
> >---------------------------------------------------------------------------------------------------------------------------------------------|
>
> Rich,
> I think we could eliminate the dual key management issue (for portals)
> if we view transient entities as "keys" that
> identify a unique runtime consumer instance of a portlet/entity. In such
> circumstance we could have the consumer
> define/provide this vs. the current proposal that it is producer generated.
> Its easy to imagine that a consumer could
> write an algorithm that allows its to reconstruct such and ID vs.
> remember/manage them. Of course this assumes the
> consumer has some persistent representation of its structure. This is
> common for most (all?) portals. If we merely
> have a transient consumer then it would have to rely/manage the dual keys.
> -Mike-
>
> Rich Thompson wrote:
>
> > I think this is a reasonable description. One of the downsides to the
> first
> > approach (OO oriented) is that is requires a particular scoping of
> sessions
> > and transient entities (namely one would pass a session into the
> > createTransientEntity call). A downside of the second approach (web-app
> > oriented) is that Consumers are required to manage the complexity of dual
> > keys. This downside becomes an advantage in a common portal scenario
> where
> > a page may look to present the output of 10+ distinct entityTypes to
> > 40,000+ users. Managing dual keys (web-app approach) results in 40,010
> > references to manage while the single reference style (OO approach)
> results
> > in 400,000 references.
> >
> > If we choose the complexity of managing dual keys, I do think Charlie's
> > suggestion of publishing all properties as logically belonging to the
> > entity even if the entity chooses to store them in the session will be
> > important in keeping the complexity manageable for the more advanced WSIA
> > use cases.
> >
> >
> > Eilon Reshef
> > <eilon.reshef@webc To:
> wsia@lists.oasis-open, wsrp@lists.oasis-open.org
> > ollage.com> cc:
> > Subject: [wsrp]
> Soliciting a Discussion around Transient Entities
> > 06/11/2002 03:20
> > PM
> >
> >
> >
> > Hi,
> >
> > Following today's joint committee call, I would like to start a
> > discussion around the transient entities issue to try to make progress,
> > despite the natural difficulty to do it over e-mail.
> >
> > Here are my thoughts:
> >
> > Entities are Producer objects with which the run-time interactions
> > logically occur. Namely, each invocation of performAction and
> > getFragment must pass an entity handle so that the Producer would
> > associate it with the relevant logical object.
> >
> > Persistent entities are pre-configured objects that are stored by the
> > Producer.
> >
> > Transient entities are temporary copies of persistent entities that are
> > supplied to enable the Consumer to use entities without the need to
> > de-allocate them. One example I used in a previous e-mail is a page that
> > has multiple copies of a map service, each with its own dynamic
> > configuration data.
> >
> > Entities are always explicitly created by the Consumer.
> >
> > I think that the confusion lies in two areas (I hope that I am quoting
> > people right, if not, please excuse me).
> >
> > Some people (Gil, Ravi) suggested that if we require the Consumer to
> > create a transient entity each time it uses a remote portlet, then there
> > is no need for a session object. This is because this transient entity
> > can encode the session id. Others (Mike) claimed that this results in
> > inefficiencies because the Consumer would have to maintain handles to
> > transient entities which it doesn't really need.
> >
> > I think that the source of this confusion is the background. Requiring a
> > transient handle is very natural in object-oriented thinking, where
> > persistent entities (classes) are "instantiated" into transient entities
> > (objects). Not requiring a transient handle is very natural in Web
> > architecture thinking, where a single servlet (or a single entity) can
> > serve multiple requests - whether that entity is persistent or even if
> > it is transient.
> >
> > If we take the second approach and follow the Web architecture line of
> > thinking, then (as Mike suggested) transient entities may be created
> > arbitrarily by the Consumer for scoping purposes, and hence may span
> > multiple users. That prevents them from providing a superset of sessions
> > even if performance wasn't a consideration. This is not to say that it
> > isn't likely that transient entities will be created on a per-user basis
> > (just like persistent ones), only that it's completely arbitrary.
> >
> > It seems that we need to decide between the two options.
> >
> > If we take the second approach (the Web architecture one), then the
> > transient entity concept is completely orthogonal to the concept of a
> > session, which is a scope that allows the Producer to store data across
> > portlets (and within an individual portlet, if no transient entities are
> > used). The main lingering question around sessions is the mechanism
> > around them. The mechanism proposed in the latest draft relies on
> > explicit creation of sessions to support the entire functionality set,
> > but this needs to be discussed further.
> >
> > Does this description make sense? Any observations from the debating
> > group (Mike, Ravi, Carsten, Gil, Rich, ...)?
> >
> > ----------------------------------------------------------------
> > 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