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 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                                                                               


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

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>

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

Powered by eList eXpress LLC