[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] Soliciting a Discussion around Transient Entities
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