MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] FW: [wsrp] Soliciting a Discussion around Transient Entities
Title: Message
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>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC