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

Eilon - my comments are embedded in [CL] tags.

Best regards
Carsten Leue

Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

|         |           Eilon Reshef      |
|         |           <eilon.reshef@webc|
|         |           ollage.com>       |
|         |                             |
|         |           06/11/2002 09:20  |
|         |           PM                |
|         |           Please respond to |
|         |           Eilon Reshef      |
|         |                             |
  |                                                                                                                                             |
  |       To:       wsia@lists.oasis-open, wsrp@lists.oasis-open.org                                                                            |
  |       cc:                                                                                                                                   |
  |       Subject:  [wsrp] Soliciting a Discussion around Transient Entities                                                                    |
  |                                                                                                                                             |
  |                                                                                                                                             |


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.

I agree in general but would like to point out that the entities do not
only make sense in runtime context. In special persistent entities live
longer than the duration of the interaction.
For me an entity is any logical object hosted by the producer.

Persistent entities are pre-configured objects that are stored by the

Persistent entities might be pre-configured but this is not an essential
feature of this entity type. The essential feature of a persistent entity
is that it preserves state even after the interaction has timed out or
consumer/producer have been restarted.

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.

Why should a transient entity be tied to a persistent entity? For me a
transient entitiy is simply a server hosted object that becomes invalid
after the interaction has timed out. It may be generated from a persistent
entity but this is not a must.

Entities are always explicitly created by the Consumer.

I think that this is still subject to discussion.

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.

This is not my understanding.
From my point of view the consumer can use the persistent entity (that
represents a portlet on a page) directly without creating a transient
entity. Why should he? Interaction specific data would be stored in the
session object.
Transient entities will be created if it is explicitly not desired that the
object's state will be persisted. This could be the case when a portlet
enters a configuration mode and only wants to persist the changes made in
this mode if the user confirms them. In this case the transient entity
would be transformed to a persistent one.
Another usecase for a transient entity would be a (remote) portlet that
displays transient data like the result of a search. This would never be

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.

See my comment above: both persistent and transient entities are "objects"
in a programming point view.

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.

If we take the third approach and see both transient and persistent
entities as "objects" then sessions are also orthogonal. They represent the
"interaction state" of the user (possibly spanning multiple entities)
whereas the entities represent the object's intrinsic state.

I think we really need to get to a common understanding of such basic terms
as entities, preferably already before the F2F.


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