[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 | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| 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. [CL] 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. [CL] Persistent entities are pre-configured objects that are stored by the Producer. [CL] 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. [CL] 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. [CL] 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. [CL] Entities are always explicitly created by the Consumer. [CL] I think that this is still subject to discussion. [CL] 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. [CL] 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 persisted. [CL] 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. [CL] See my comment above: both persistent and transient entities are "objects" in a programming point view. [CL] 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. [CL] 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. [CL] 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