OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [wsrp] Soliciting a Discussion around Transient Entities

   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.

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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC