← Prev in month ← Prev in thread
Next in thread → Next in month →

[wsia] FW: [wsrp] Soliciting a Discussion around Transient Entities

From
Eilon Reshef <>
Date
2002-06-11T19:24:31+00:00
ID
007401c2117d$95a9c2b0$ea0aa8c0@eilon
Thread
[wsia] FW: [wsrp] Soliciting a Discussion around Transient Entities
Title: Message

 

-----Original Message-----
From: Eilon Reshef 
[mailto:] 
Sent: Tuesday, June 11, 2002 
3:20 PM
To: -open; 

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

---------------------------------------------------------------- 

To subscribe or unsubscribe from this elist use the 
subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl>
← Prev in month ← Prev in thread
Next in thread → Next in month →