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: [wsrp] Soliciting a Discussion around Transient Entities


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, ...)?



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


Powered by eList eXpress LLC